丁宇 | blog

厌倦了身为UI设计师却只能在既定需求范围内做文章？或者作为产品经理却被UI设计师“剥夺”了设计细节或写代码的乐趣？那你应该像我一样对Facebook的这个Product Designer职位感兴趣，它的JD如下：

• Be at the intersection of product and engineering to prototype, design and build new features for an audience of millions
• Design and ship products of the highest quality with the clean consistent style that Facebook is known for
• Implement and extend the style guidelines with the rest of the design team

别的不说，光是第一条就让人格外心动了！既能在研究中发现用户需求，又能为这个需求设计合适的产品及UI，更可以自行编码。这才好玩嘛！没有拉下任何乐趣。

而第二及第三条则充分体现了一个“理智”且有潜力的设计团队应该做的事儿：把工作形成规范。

什么样的人能适合这样的工作呢？继续JD（部分）：

• Strong portfolio featuring interaction design samples
• Expertise in PHP, Unix, XHTML, CSS, Javascript, AJAX

瞧见了没，设计和技术并没有分家，你既要有设计能力，还得有技术背景。

这真是一个非常有趣的职位，不知国内互联网可有类似的机会？

上文讲到过分工不合适的原因，这次想和大家探讨一下我的一些关于如何解决问题的想法：

1. “架构＋设计＋研究”的分工

简单地说，就是架构组负责底层建设和方向引领，设计组负责设计和实现，研究组负责（部分的）用户研究和可用性测试。详细介绍可查看以前写的《说说互联网公司内设计师的分工》。这种分工能够解决上述的大部分问题。

此外，正如jean.ma所说，在项目内的分工，应遵循“按模块而非角色”的方式来进行（这点我在《说说互联网公司内设计师的分工》也说过），就是不同的设计师负责产品不同的部分，然后由一名总设计师来统筹兼顾。

2. 知识管理、文档管理和版本控制

专门设立一台服务器，使用开源工具（比如Drupal），将所有的项目相关文档都进行集中的统一存放和管理，使任何事情有据可查，减少沟通成本，消灭“产出物发给了A部门，忘了发B部门”，或是某人说“我找不到你发的Demo了再发一次”的问题。

如果你的部门使用Dreamweaver作为设计和开发工具，那就更好了！让架构组把最新的Dreamweaver模板和代码片断上传到服务器上，然后每个人打开Dreamweaver时第一件事情就是更新本地模板和代码片断（DW早就有此功能），这样不仅协同起来效率很高，而且质量可控性很好。可以说，这在一定程度上实现了开发使用Eclipse+SVN进行协同工作的效果。

至于版本控制，一方面，给每一份产出指定一个唯一且明确的版本号，所有项目组成员交流时以版本号而不是“最新”一词为准，消灭歧义和不确定性。

另一方面，如果你使用CVS或SVN进行版本控制，一定要把我们设计或开发的版本（也就是使用CVS或SVN进行版本控制的版本，以下简称trunk版）和给项目组演示的版本（采取手工方式进行版本控制，以下简称milestone版）分开，这样不仅可以加快我们的开发效率，更重要之处在于减少许多沟通成本。

比如，假设你上午9点通知业务部门及开发部门，说某项目的Demo已经做好，访问服务器即可查看，一般情况下你并不能保证所有人都在接到你的通知后立即查看 Demo，很可能有的人是在9：30分看到，有的在10：00看到，甚至有的在第二天才看到。这期间你很可能会根据业务部门或是开发部门的反馈对Demo 进行了修改（哪怕是小修小补），那么这样一来，大家讨论的基础 - 统一的版本就不复存在了。

我们可以借鉴程序员的做法，将trunk和milestone分开：平时在trunk上提交各类修改，如果需要展示给他人，则另外拷贝一份milestone版本（或新打一个分支，但此时意义不大）。比如你调试和预览的地址为 http://ued-server/demo/project-a/ ，当需要展示时，将project-a目录复制一份到 http://ued-server/demo/project-a/milestones/1 ，并以此作为第一个milestone。项目组成员在沟通时，都以milestone为基础。

3. 把视图（view）交给它本来的主人－前端开发（甚至设计师）－去处理

由于模板里常常混杂着HTML和程序语言（暂且以PHP为例），而这两种东西又分别来自于UED和开发两个部门，因此无论是编写还是调试模板，都要牵涉前端开发和程序员的精力。工作职责模糊不清，权责也很难界定。关系好的程序员曾私底下和我报怨说“如果连HTML/CSS/Javascript这些东西我们都写了，还要UED的人干吗”，虽然HTML/CSS/Javascript我都是尽可能完整产出，并且这句话也有其偏颇之处，但我仍对此深觉惭愧。

“模型（model）－视图（view）－控制器（controller）”架构的重要目的之一，就是把视图尽可能与逻辑和数据分开。当以模板的形式把视图分出来以后，为了尽可能地降低模板的复杂性、又同时保持模板具有一定的逻辑和数据处理能力，让不那么熟悉程序的人也能够控制如何显示，人们才开发了各种模板语言，比如PHP中的Smarty和Java中的Velocity。也就是说，这种极度简化的模板语言就是专门给设计人员提供的，它甚至不会比Javascript更复杂！

当把视图部分的工作完全交给UED后，开发和UED的合作可以以这样的方式进行：1）UED提供原型；2）开发按照原型提供所需的逻辑和数据（通常是一大堆if...else...和$username等变量）；3）如果有必要，可以要开发按原型来写一个不考虑内容及样式的模板，模板里包含了所有必须的逻辑和数据；4）UED将逻辑、数据和各种前端代码编写进模板。

这个方案我曾和系分及程序员讨论过几次，我们都认为它是可行的。出于可维护的角度考虑，他们其实也愿意将模板的编写工作交给UED。

此方案的优点是显而易见的：开发和UED终于可以真正地各司其职，大家权责明确，从项目管理的角度来说，UED的工作时间计算也更为准确，以前那种“UED协助调试模板，花了大量时间却没有被记录进项目”的情况不会出现。

缺点当然也不是没有，在方案实施初期，UED一定会有阵痛，尤其是对那些从没有接触过后台编程的设计师。

4. 强调工具和规范的重要性，而非某个人的聪明才智

天涯上前段时间流行一篇名为《做单》的小说，里面有一句话印象很深：

“外企更像是一个集团军……民营企业都像是个游击队或者是特种部队……集团军最大的特点就是随便换掉某个人或者某几个人对整个军队没有任何影响，游击队就不能承受这种变化。

国内的企业面临最大的问题就是从游击队向集团军的转变中，因为人意识的转变跟不上，而导致转型失败……一个民营企业要想做大，必须经历这种从游击队向集团军的转变。”

关于规范说得够多了，还是说说工具吧。

从团队的角度来说，工具主要的目的就是最大限度地统一和标准化产出物，提升团队的工作效率和质量。因此以下提及的工具都是与这个目的相关：

1. Dreamweaver。它内建Templates和Code snippets功能，并支持从服务器上同步，如果整个部门都使用Dreamweaver的话，那么大家的Templates和Code snippets就全是规范的；
2. 框架。无须赘言，好的框架可以让你3分钟做完原本需要10分钟的事情，并且产出物（典型如代码）高度规范；
3. 文档库。比如前文提到的VelocityDoc，有了这东西，设计师可以在短时间内了解整个网站的模板，包括模板整体的结构、每个模板的作者、功用、所引用的CSS/Javascript，以及它所属的layout和所包含的control/element等等。对于新同事来说，文档是最好的老师；
4. 封装。努力地将常用的东西封装成模块，避免重复劳动，同时也能降低对设计师的技能要求。比如说对于表单界面，交互设计师根据不同的错误情况，需要制作出不同的原型，费时费力，还容易出错，如果封装一下，设计师只按照一定格式提供错误提示的内容就好了，剩下的什么都不用管，全交给系统自动处理。

上面讲得有点太干巴巴了，这里有一个06年做的东西－代码助手－算是上述思想的一个集中体现吧。

关于分工的话题暂且到此为止吧，这么枯燥冗长的内容不知有多少人可以坚持读完，呵呵。

JunChen在最近的一篇《为何XHTML原型会失败》中说出了一个实质问题，即在快速变化的互联网公司中，非XHTML原型只是“看上去很美”而已。

究其原因。除了JunChen提到的“难以维护”以外，对设计和开发人员精力的消耗也是一个重要方面。

让我们来看一个典型的流程：

1. 用户研究员进行用户研究，根据结果编写了研究报告（比如角色模型和使用场景）；
2. 交互设计师按照用户研究报告，设计了线框图；
3. 视觉设计师拿到线框图，和交互设计师讨论并沟通后，进行视觉设计并输出高保真视觉原型；
4. 前端开发工程师拿到视觉原型，在和交互设计师及视觉设计师沟通后，进行编码工作，输出HTML文件；
5. 用户研究员开始可用性测试，并将问题反馈给交互设计师；
6. 回到第一步，直至用户研究员（或其他的什么人）认为质量合格。

这一看似合理的流水线作业存在什么问题呢？让我们来仔细分析一下：

1. 困惑的交互设计师

用户研究是一个渐进式接近真相的过程，其结果不可能一步到位。尤其在研究初期，哪些因素会对产品设计有较大影响，哪些因素实际无足轻重，这是没有办法事先准确预估的。这就造成当交互设计师在依照研究结果设计时，发现研究结果不能给自己的设计以有力的支撑。

比如，当两种交互方式都可以达到同样目的、而从已有的数据中又无法判断用户会喜欢哪种时，交互设计师就会犹豫不决。从资源的角度来考虑，请研究员再一次制订计划、招募用户并实施研究，是不太可能的；更不用说设计两种原型并分别测试了。因此此时交互设计师只能依据自己的经验，或者进行押宝。

此外，交互设计师还面临一个颇为尴尬的问题：由于处于流程中的中间环节，缺少坚实的硬性产出，他很难、甚至没办法证明自己的工作价值。一方面，交互设计是一种偏“软”的技能，它目前没有、将来也很难产生一个标准化的量尺来考量其自身的质量。可用性测试可以做到部分量化，比如完成时间、出错次数等，但十几个人（一般甚至更少）的数据在统计学上是没有任何意义的。而且，有多少用户能理解那种低保真的原型呢？另一方面，就算用Axure等软件制作可操作的原型然后拿去做测试，各个业务部门会相信测试结果么？没错，你可以强硬一些，比如采取“如果业务部门不参与观察测试，就算自动放弃决策时的发言权”这样的办法，可这只能说你有工作方法，这实在无益于专业技能的提升。而且有多少设计师可以强势到让所有的业务部门闭嘴的？

实施社会分工的目的之一，就是实施标准化的作业。而当流水线中某一环节的产出物质量，是随着其作者的经验而变化时，也就是说质量并不能定量控制时，分工的意义就不复存在，这一生产方式也就不可能按简单复制的方式扩张规模。

2. 交互、视觉和前端间的沟通成本，和可能的不愉快

在交互设计师和视觉设计师交接工作时，沟通不可避免。视觉设计师要充分领会交互设计师的意图，这需要沟通；反过来视觉设计师给交互设计师的线框图提意见，这也需要沟通。尤其在整个部门缺乏UI规范时，沟通成本可能会高得吓人。比如交互设计师认为某处需要用3级标题（比如h3），到了视觉这里直接用了一行红字。所以常常觉得“有那时间费力沟通，还不如直接改了算了”。结果改完了交互设计师心里会想“你怎么也不和我打声招呼就改了”，不愉快就这么来了。

到了前端开发那里，问题就更复杂了。首先，前端开发需要实现所有细节，而出于资源上的考虑，这些细节未必都会由交互和视觉设计师的产出物覆盖到（比如同一页面上仅有一处文字有微小变化，那么线框图和视觉稿要分别做两份吗？），那么前端开发就需要经常和前面两者沟通；其次，如果前端开发发觉设计稿的实现难度或成本太高，那么情况就更为棘手，最麻烦的莫过于要重新设计交互原型。

当然，上述问题基本都能靠沟通解决，问题是，你愿意花多少时间去沟通呢？从这个角度来说，敏捷开发的沟通成本是最低的，因为沟通就是产出。而反过来上述流程的沟通成本很高，因为沟通是用来解释产出的，是产出成本之外的“额外成本”。

3. 瀑布模型与生俱来的缺陷

上述流程是一个典型的瀑布模型，一旦在可用性测试阶段发现问题，就需要重新再走整个流程，其效率之低可想而知。此外，由于涉及到的环节和人员不少，流程走得次数越多，出问题的机会也越多。最常见的是各个环节的产出物版本控制困难，甚至根本没有版本控制，结果往往造成项目组中每个人拿到的产出物（如Demo）都不一样，这是一个非常可怕的风险，会给项目过程和质量带来非常严重的影响。

我对这个问题采取过“文档管理＋版本控制＋减少分工”的方法，效果很好。这个后文会阐述，这里先不展开。

4. 无技术含量可言的重复劳动

在一些页面调整不大的日常项目中，交互设计师用2小时做的原型，到了前端那里可能半个小时就把HTML搞定了，如果用CSSEdit那样的工具，实现过程甚至更快、更惬意。那么，为什么要把原本一件很小的工作硬生生地拆成两部分来做呢？

举一个非常常见的例子：业务部门提需求说要改某某宣传文案，如果按照上述流程，交互先做线框，给到视觉确认，然后到前端修改，往最快了说也得半小时吧。而若交互设计师直接改HTML，十分钟搞定。

有人说找到相应的模板还要时间呢，这好办，做个可搜索的模板库就好了。我们曾参考DocBlock规范做过VelocityDoc，效果很好。

5. 破坏了网页设计工作本身的美感

网页设计是技术和艺术的结合，一个优秀的设计师不仅大量吸收传统的设计知识（如平面设计），更懂得如何利用合适的技术去带来艺术上的创新。这个过程是相辅相成的，硬性拆开只会限制设计师的创造力。

这就好像搞油画的必须要掌握不同染料和画布的性质，搞雕塑的既要有创意又有能动手（你能想象出一个雕塑家只管创意而从不亲自去实现吗）一样，使用技术来展现艺术，借助艺术去探究可能的技术。

据说Apple的工业设计师都要清楚地理解各种材料的特点的，如果只让他们画图，Unibody这样的杰作又如何诞生？

说了半天问题，下篇中我们来看怎么解决。

第一天的印象和笔记见这里。

量化和评估用户体验

在这次的UF2008大会上，我不止一次听到了有人提到量化用户体验的重要性，如黄峰在他的主题演讲中，强调在每一个版本发布前后，要通过数据对结果进行对比衡量；再如Sarah在其“如何将用户体验带入一个IT企业”的工作坊中，指出“UI设计是主观、不可衡量”是“一些管理人员常见的错误认识”。这些实际上是和我的观点相一致的，在我总结整理的用户体验框架中，清晰、明确、可衡量的目标是重中之重，也是后续所有工作的目标和基础。

借着这次大会的机会，我把我的用户体验框架和一些朋友做了分享，正面和负面的评价都有，我自己收获也不少，这里不妨简要介绍一下：

这个框架的想法来源于两个方面，一是用户体验设计在目前并没有一套通用的方法和流程，一些人有自己的一套做法，另外一些人则尚在摸索。即使是同一个公司内，每个人的做事方式可能也不同，这样的现状不仅给刚入行的设计师带来困惑，使他们不知从何入手，也造成其他设计师之间口径的不一致，以致提高了沟通成本。另一方面，是与用户体验设计一墙之隔的程序开发，却有着非常成熟的流程、方法和工具，在程序设计中，框架的使用可以极大地提高工作效率，减少各种成本，并提供了非次高的统一性和扩展性，那为什么不把这种框架的思想引入到用户体验设计中来呢？

正是基于上述两点考虑，我才于年初提出了“用户体验架构”的概念，经过差不多一年的发展，我将“用户体验架构”一分为二：

1. 框架。用于给单个设计师提供一个类似于程序开发中的、标准化的流程和工具，设计师可以按照框架中定义的流程、使用其中的方法来进行工作。这一框架包括1）定义清晰、明确并可量化的商业需求；2）实施用户研究；3）定义清晰、明确并可量化的用户体验需求；4）编写设计规范，提供设计工具；5）实施TDD（测试驱动设计）；6）用户体验评估等六个部分。具体内容不在这里展开，不过我相信标题已经有很大的自明性了。从朋友们初步的反馈来看，这个框架还算不错，达到了我的预期。

2. 分工。我明确反对过细的分工，这个提过好几次了，这里不再赘述。

用户研究的价值

“以用户为中心”就要去做用户研究，搞明白用户及其需求，才是做出好设计的一个基础。很多时候，用户研究做好了，解决问题的办法自然而然也就出来了。UF2008大会上有好多场主题演讲都是关于用户研究的，虽然内容都不是很深入，但非常好地强调了研究的重要性。

回想一下自己写过的几篇相关文章，有讲虚拟社区中用户行为的“An Automated Tool for Managing Interactions in Virtual Communities”有讲问卷设计的“可用性测试中常用的问卷量表”，有用于信息架构的“卡片分类测试实施攻略”，有关于用户访谈的“绝望主持人”系列（第一季、第二季、第三季）等等。

亚洲（东亚、南亚）用户的特点

来自印度埃森哲的Sushmita Munshi给我们做了一次非常精彩的演讲，题目为“ 亚洲青年：重新定义用户研究和设计去满足亚洲最大的目标用户群即青年正在不断改变的习惯和期望”。嗯，她的题目能把读者憋死，但侥幸活下来的话，就能听到非常有趣的内容。我听下来她的演讲主要包含了两个部分，一是亚洲青年用户的特点，她所谓的青年指的是1980年至1989年出生的这一代人，Sushmita精辟地总结了这一代人所拥有的一些特点，如独生子女、大量受到美国文化的影响等等；二是如何如何针对这些用户的特点作研究。

期间她提到说如果用户为年轻的女性，那么采用男性主持人是不合适的做法，可她没有解释原因。于是我脱口而出：“why（为什么）”？坐我旁边的是Infosys的设计副总裁Sridhar Marri，他听到后大笑不止，说：“they will love him（怕她们爱上他）”，果然猥琐。

在企业文化基础上推广和实施用户体验活动

这是听Sarah Bloomer的那场“如何将用户体验带入一个IT企业”学到的内容。她的意思是，你得判断所在企业的风格和文化是什么，是技术型？设计型？还是市场型？对于市场型公司来说，设计师的专业能力并不是首当其冲要考虑的，而能否和市场及销售部门有效沟通、能否使这些业务部门相信甚至理解可用性才是最重要的。我对此深表赞同。国内成功的技术型互联网公司很少，而在大部分的市场型公司中，可用性的推广和地位又多少成问题，Sarah的观点对此很有借鉴意义。

敏捷方法

敏捷开发越来越流行和普遍，在这种情况下实施用户体验设计和以往有什么不同，是个值得引起注意的问题。在Sarah的讲座中，她花了相当大的篇幅来讨论敏捷，可惜我敏捷的实践经验少得可怜，只记得她采取换人的方式来避免精疲力尽（burnout）比较有意思。

此外，我当时问了个关于敏捷开发中UI规范的问题，她的答复有些自相矛盾，她说应成立一个单独的小组用于制定各种规范和工具，但另一方面她自己也提到说敏捷的一大特点就是没有文档，因此这两种做法实际上是冲突的。

已经是深夜了，先写这么多吧。

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

先说架构组

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

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

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

再说用户研究组

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

最后说设计师组

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

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

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

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

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

另起一段，休息一下。

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

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

丁宇，08年3月25日夜

继续阅读：为什么网页设计不应强调分工 1（08年12月15日更新）