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

先说架构组

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

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

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

再说用户研究组

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

最后说设计师组

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

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

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

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

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

另起一段，休息一下。

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

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

丁宇，08年3月25日夜