我坚信一点：对于大部分互联网公司来说，设计师完全不需要太多的分工，我认为一个小而精的架构组、一个用户研究组和一个设计师组就能够很好的适应互联网公司的需求了。

先说架构组

就像软件开发中的情况一样，架构组中个个都是高手。这个组对整个设计团队的设计质量和工作效率起决定作用，它负责制定设计目标和设计哲学、提供设计规范和工具、探索和引入新的设计和技术，并且引领整个设计团队和公司产品在用户体验上的发展方向。

这个组在行政上必须拥有绝对的权利，并要有完善的制度和流程，来保障架构组成员能够使用上述权利去控制设计的质量。Apple为什么能持续不断地产出高质量的设计？这是和Jobs本人对设计质量的无限追求和至高无上的行政权力分不开的。

此外，架构组绝对不是脱离产品设计实践去搞高精尖的东西，实际上，其中成员必须积极地投入到产品的设计和研发过程中，身体力行的检验和更新自己的工作成果。

再说用户研究组

用户研究组没啥好说的，能把两件事儿做好就行：用户调研和用户测试。

最后说设计师组

坚决反对搞那些花里胡哨的分工名堂，比如什么“交互设计师”（或“用户体验设计师”，UE）、“前端开发工程师”和“视觉设计师”等等。除非你的产品确实有大量且复杂的前端开发和视觉设计工作量，否则过细的分工只会降低工作效率、增加沟通成本，并最终导致设计质量不高。

此外，“交互设计师”（或“用户体验设计师”，UE）的进入门槛有多高，相信大家都心知肚明。更何况，“交互设计”这个概念本身如何定义，“交互设计师”的工作职能包括哪些，又如何去衡量他的工作成绩等问题仍是没有定论。一个典型的现状就是，同样一个名称为“交互设计师”的职位，在各个公司的职能可能是千差万别的，这点随便参加一个行业会议就能立即感受到。因此在现阶段下，我完全看不出单独设立一个只做“交互”的“交互设计师”这一岗位的必要。

那么这个设计师组中的成员该叫什么呢？这并不是最重要的，关键在于搞清楚他们的职能范围。

对于相当一部分互联网公司的设计团队来说，这个设计师组中的成员应该实行包干制：从部分用户研究到设计再到代码实现都一包到底。网站的设计不像软件开发，前者通常要在极短的时间里实施一个完整的“调研－设计－实现”流程，这就在客观上要求流程中不能有过细的分工和过多的步骤，经手的人越多，效率越低；此外，和软件相比，网页的实现难度完全不是一个数量级上的，说难听点，把一个智商正常的成年人送去学上一个月的HTML/CSS，就可以处理互联网公司的大部分日常需求，7、8年前我在外面讲课时，有些具备FoxPro基础的学员一个月后连Javascript都写的有模有样了，可你让他学一个月的Java看看？因此，实现技术的低门槛为一个设计师实行包干制创造了必要条件。

但并不是所有设计师的工作职能都是一样的：必须把具备较高能力的人提升为主设计师（或资深设计师），由他来带领其它普通的设计师工作。此时，他的角色非常类似于程序开发中的“系统分析员”，在一个产品项目中，他的设计规划将作为其它普通设计师的工作基础。比如他为这个产品设定了怎样的用户体验目标、采用了怎样的设计思想和哲学、选取了何种规范和工具等等，他还要做一些类似项目管理的工作，以便更好地让不同的设计师协作。实际上，可以考虑让架构组的成员兼任产品项目中主设计师的工作，这样既可以发挥他们的高水平，又可以让他们对各种规范的实施情况有一个切身的体会。

另起一段，休息一下。

之所以写这篇文章，一是因为我觉得我提出的“用户体验架构”这一概念，不仅要适用于单个设计师，更要涵盖团队建设的方法，否则称为“架构”就未免显得有些单薄，写完此文后，我感觉我的“用户体验架构”已经有一定的雏形了，接下来的工作就是尽快把它用图示辅以文字的形式整理出来；写这篇文章的第二个缘由是，我下午参加公司的设计沙龙时意外地发现，原来不仅是我，几乎部门内所有的设计师都对“交互设计师”的岗位职能感到模糊（虽然我是“用户体验设计师”，可谁能告诉我这是个什么职位？），并且也都或多或少的表达了“不满意分工过细”的观点；第三，我一直觉得“网页设计师”这个说法没什么不好－一些早期网页设计师的作品一样注重可用性和用户体验。

最后必须要说明的是：1）我目前并没有机会去从管理者的角度实践上述方案，但它是我根据自己的经验，不断摸索和总结出来的想法。如果你认同我的观点并付诸实施，请务必告诉我你的心得体会；2）各个公司的情况不同，我仅以与支付宝类似的网站为例。

丁宇，08年3月25日夜

第一次来？先看看“有感于与三通的对话”和“初探用户体验架构（“有感于与三通的对话”续篇）”，否则可能看完了都不知道我到底要说啥。看过前两篇的请继续往下读，接着批判。

确立设计流程和各阶段交付物

如果说界面设计的哲学还能凭感觉胡说几句的话，这个设计流程和交付物可绝对是马虎不来的，因为其质量的高低将直接影响最终的设计质量。

一般来说，采用UCD的流程大体上遵循“研究－设计－测试－实现”这样一个流程，所不同的只在于，1）是使用类似开发中“瀑布”还是“敏捷”的方法；2）每个阶段的产出物及其衡量标准。对于第一个不同，似乎传统行业倾向于使用“瀑布模型”，而互联网公司更倾向于“敏捷”。第二个不同则大有文章可作－相对于设计流程，对各阶段交付物质量的把控显然更为重要，因为流程本身最重要的作用，就是在一定效率下保证合格交付物的产出。那么，前文一再谈到的规范，就正是作用于这些交付物。合理的规范不仅可以极大的提高工作效率，更重要的意义在于保证交付物具有一定的质量。

为了避免讨论太空洞，下面我将以一直在参与的一款产品（以下简称“A产品”）为例，说说我在推广的一些规范（值得一提的是，由于可能涉及信息保密问题，我只能大致讲下概括）：

“A产品”UI编码规范 v0.5

• 简介：总结、归纳和整理“A产品”在Velocity模板、XHTML、CSS和Javascript等方面的编码规范。
• 组成部分：《“A产品”UI编码规范 v0.5》、“‘A产品’CSS文档库”和“‘A产品’Javascript文档库”。
• 价值及意义：提升UE/UI、开发和测试的工作效率，降低工作成本，通过统一化的代码控制质量。

“A产品”视觉设计规范 v0.1

• 简介：总结、归纳和整理“A产品”在视觉上所应具有的风格。
• 组成部分：《“A产品”视觉设计规范 v0.1》。
• 价值及意义：提升UE/UI团队内部的工作效率，降低沟通成本，探索产品自身的设计风格。以后新设计师加入项目组时，此文档将起到培训的作用。

“A产品”信息提示管理规范 v0.1

• 简介：对“A产品”相关页面的信息提示进行统一管理和存储……
• 组成部分：《“A产品”信息提示管理规范 v0.1》。
• 价值及意义：避免出现遗漏信息提示、信息提示中文案不好的问题，减少工作成本。

“A产品”Demo版本控制方法 v0.2

• 简介：在多人协作时，通过这个方法来管理每个人的交付物，做到在trunk上设计和开发，在milestones上演示……
• 组成部分：《“A产品”Demo版本控制方法 v0.2》。
• 价值及意义：提高多人协作的工作效率，降低项目组成员间的沟通成本。

“A产品”UI控件使用规范 v0.1

• 简介：统一界面的布局和控件的使用，给用户统一的体验……

“A产品”文案写作规范 v0.1

• 简介：统一文案的文风及措辞，减少歧义，用简洁、通俗且专业的语言给用户引导和帮助。

规范看起来很多？其实在一个拥有复杂业务逻辑、许多不同部门的人协作的项目中，一些明确清晰的文档只会减少沟通成本。

未完待续，白鸦别急，呵呵 ：）

如果你没读过我之前的那篇“有感于与三通的对话”的话，我强烈建议你先花几分钟时间去看看，因为本文将在这篇文章的基础上展开进一步的讨论。

我上次提到了“规范”的重要性，其实“规范”这个词本身具有相当大的歧义，因为往小了说，它可能就体现为一些文档什么的；往大了说，什么东西都可以装在“规范”这个篮子里。为了避免让人联想起“规范文档专员”或是《1984》中“老大哥”（Big Brother）那样的形象，我借用了“架构”这个词，来形容此类工作，考虑这些事情的人，自然冠以“用户体验架构师”最为合适（我猜白鸦就是在做类似的工作，虽然他自己可能不这么叫）。

用户体验架构师是什么？估计100个人有至少100种说法。我觉得老冒提的“统筹和管理设计”这个概念很有意思，有效地引领、统筹、管理和规范设计应该是用户体验架构师最重要的工作职责之一，但我现在还不确定可不可以把这个“之一”拿掉。我非常希望白鸦能分享一下这块的经验，在我的概念中，他所提供的咨询服务就是为了解决设计部门（可能还包括产品部门）大方向和规范的问题。

那么用户体验架构师做哪些事情呢？至少应该包括以下一些：

确定界面设计的哲学

这个“哲学”包括：1）你这个产品或设计总体上想给人什么感觉？是Apple的灵活和酷，还是IBM的刻板和严谨？是KFC的明亮洁净，还是PizzaHut的温暖舒适？这个问题很重要，是指导设计师工作的基础。当遇到设计规范文档中没有描述的情况时，这个“总体感觉”就是发散和延伸的基础了。但是，这个恐怕也是最难总结和归纳的，Apple也是历经了几起几落后才确立了“酷”的风格（参见《苹果电脑案例》）；2）设计遵循“广且浅”还是“窄且深”的信息架构？Apple的设计非常明显带有“窄且深”的特点，一般来说它只会将最最常用的少数几个按钮放在面板上，其余的功能则逐级放在菜单或辅助面板上（其实也不是特别深），比如iWork中的幻灯片制作软件Keynote（如下图），实际上，它大部分软件都是如此，我已经养成了非常统一的操作习惯，我也很乐意养成这样的习惯，因为预期和结果具有高度一致性。反观MS的Word/Excel，我相信没人不记得上面那数十个按钮吧！MS给我的感觉是尽可能的把功能暴露在外面，它所采用的信息架构和Apple的就有明显区别。

未完待续……

2008年1月3日凌晨更新，推荐继续阅读我后来的几篇文章：

• 初探用户体验架构 2

晚上去参加“D2前端技术论坛”，结束出来时遇到了淘宝UED的视觉主管三通，便和他探讨起UED部门角色分工、流程和设计质量管理的问题。没想到在这样的问题上我们居然心有戚戚焉，有些相关的想法不吐不快，遂第一时间记录在这里。

我们开始此番讨论，源于我的一个关于淘宝UED角色分工的问题：在淘宝UED部门中，是采用单兵作战，即每个设计师独立承担项目中的所有角色，再辅以各领域专家（如研究、视觉和代码）的方式，还是按照设计师的专业方向，为其划分明确的职能范围？三通的答案很有意思，他说他觉得应该分一阵合一阵，因为淘宝两种方式都尝试过，总的感觉下来各有利弊。但有一点我们达成了绝对一致的意见，就是应该有一个起到架构和引领作用的小组，由它来制定整个网站的设计规范、标准和哲学，掌控每个产品及网站整体的设计质量，提升部门的设计水平，并提供基础性的工具支持。这个小组虚拟或实体都无所谓，关键在于必须有资源保证上述工作得以进行。在十几分钟的简短对话中，我们不约而同的对规范的价值一再肯定。

规范是我一直都非常非常重视的部分，它不仅仅包括对设计要求的界定，还包括了流程、方法和产出物本身。你可以把规范实现的最高境界看成：随便拉两个设计师出来，他们都可以遵循一直的设计哲学，用相同的流程和方法，产出质量相等的东西。此时人已经不是影响团队设计质量的重要因素了，团队也不会因为某个设计师的突然缺失而受到重大损失。当达到或接近这种程度时，真正重要的，就是规范本身。下午我和同事（iefen）谈话时，说了这样一句话：“人们制定规范，人们遵守规范，人们更新规范。规范进步，人也随之进步”。

这当然是一种非常理想的境界，但我坚信其方向是正确的，现实当中的例证也比比皆是。 比如，我们在学校所学到的知识，其实它们不都是完全正确的，但教育普及的结果就是低成本的提升了全民素质，降低了人与人之间的沟通成本。当科学家们把知识的内容更新后，更广大的人民受益，整个社会也随之进步。

再比如，程序开发中所使用到的各种框架，可以显著提升程序员的工作效率，保证开发质量。完全不用担心框架会限制人们的水平，因为自然有高水平的程序员会做升级框架的工作。

这样的例子举一天也举不完，但有人不同意。就像iefen说的那样：制定规范并确保它的执行，这只是一个过程，或者说做法，我们不能为了制定规范而制定规范，因为高管们并不关心规范本身，他们要的是结果。我的回答是：为什么不可以为了制定规范而制定规范？如果是制定规范这是一个过程而非目标的话，那么提升和保证设计质量也同样是个过程而非目标，因为提升和保证设计质量是为了提高可用性和用户体验，提高可用性和用户体验是为了用户更愿意使用我们的产品……按照如此逻辑推论下去，任何事情都只是过程而非目标。既然我们已经知道了其中的因果关系，不注重因，又何谈果！

所谓知易行难。三通用了一个非常恰当的词，来形容部门内基础和规范的建设，就是“公共福利”。我觉得这个词用得真tm绝了！实际上我一直在做提高“公共福利”的事情，无论是去年的“支付宝设计指南”、“代码助手”、“支付宝UI库”（类似YUI的东西），还是今年的“支付宝UI设计规范”、“支付宝模板和代码片段库”、“卡片分类测试助手”和“变形金刚”（具体用途自己猜）等等一系列的规范和工具，过程辛苦异常（其中的经历我都可以出本书了），结果不够理想，因为这是“公共福利”，因为不是今天打下去桩明天就能盖栋楼的。

说了半天规范的重要性，再花点时间来谈谈方法论的问题。作规范，说白了就三件事儿：制定规范、确保它的有效执行、建立规范更新机制。我想特别说说第二件。

确保规范的有效执行，其实是上述三件事儿中最难办到的。我最初的做法是提供文档，但我很快就发现这行不通，因为不是所有人都像我一样喜欢阅读文档，即使这个文档的内容来源于设计师自己；于是我尝试提供一些工具来辅助设计，比如前文提到的“代码助手”和“支付宝UI库”，这一方法确实有用，但效果远不如预期，根本原因在于这些工具的作用只是辅助设计，而不在设计师工作中的必经之路；于是痛定思痛之下，借鉴团队软件开发模式，我联合两位同事推出了“支付宝模板和代码片段库”（你现在在支付宝网站上看到的页面布局样式，就是其中的一部分产物），直接把符合设计规范的模板和代码片段集成到每个人所使用的Dreamweaver中，并专门设立一台服务器来提供最新的模板和代码片段源，从结果来看，这一方法的效果非常理想，可以说我现在至少能从源头上进行质量控制了。

在我的设想中，应用此方法从源头把握设计质量，后期通过架构小组审核并结合可用性测试来掌控最终设计交付物的质量（当然会有相应的审核流程和标准，时间关系不在这里展开讲了）。可惜由于种种原因，这种“中央集权式”的做法最终没能实现。我觉得除非你的团队能够一直保持高质量的设计，否则设计质量控制就是一个重要又紧急的问题，听说承志最近也在考虑类似的问题，我比较期待他的解决方案。

时间太晚了（现在是凌晨1点15分），先写到这儿吧。

2008年1月3日凌晨更新，推荐继续阅读我后来的几篇文章：

• 初探用户体验架构（“有感于与三通的对话”续篇）
• 初探用户体验架构 2