心弦

我一直比较在意页面的性能和编码质量，有时候会通过HTML代码的质量来判断一个网站的技术水平。

易趣、eBay和淘宝在网页性能和前端编码质量上的简单对比

昨天下午闲来无事，去久违的易趣转了转，发现他们的浏览器兼容性还是一如既往地好。可看看“我的易趣”页面的源代码，就觉得有点头大－不仅HTML/CSS/JS全部都混杂在一起，而且代码显得非常凌乱，还大量使用了表格来定位。当我把CSS禁用掉，再把浏览器窗口调到320像素这么宽后，网页已经基本无法阅读了。

下图是其YSlow得分，老实说，37分并不是个理想的成绩。对于这样大规模的网站来说，如何通过规范来保证多人协作编码时的质量，以提升工作效率、减少沟通成本，并且给网站提速减负，是个重要且紧急的问题。

易趣的表现让我对eBay很好奇－看看高手云集的eBay情况如何。

结果令人惊讶（如下图），“My eBay”的YSlow得分居然高达97！只有一项因为没有加Expires header而得了B，此外全部是A。这恐怕是我见过的最高的YSlow得分了。

但是这个页面的编码质量并不如想象中的好，问题和“我的易趣”页面如出一辙。强调可访问性（accessibility）的508法案似乎被eBay完全忽视掉了。

不过值得一提的是，eBay的js写得非常强悍，单从函数的命名就可见一斑了。

接下来我又测试了一下“我的淘宝”，淘宝的代码明显漂亮了很多。它的YSlow得分为39（如下图），

从上图来看，淘宝丢分主要在1）过多的引入外部资源，比如18个js和16次DNS查询；2）Apache和CDN的设置（其实根源在各种广告提供商，10个没有经gzip压缩的js里面有9个都是广告相关的）。

替前端鸣冤

有很多人不理解为什么在拥有众多高手的大型互联网站，页面的代码还能如此之乱。难道这些前端开发不知道W3C，不知道js要做到无侵入（unintrusive）么？

当然不是，其实这里面的原因挺多的，也不是一两句话能讲的清楚。在所有的原因中，以下两条可能是最关键的：

1. 缺乏规范，或者具备规范，但缺少强有力的执行机制。在前端打交道最多的三种语言中，只有Javascript算是程序语言，HTML和CSS根本就是描述性的语言。最让人头疼的是，它们远不象具有很多相同特点的XML那么严谨，自身的描述能力又不强，所以几乎不可能写出类似Java那样规范的代码来。程序语言中常用的框架，到了HTML和CSS这里也起不到作用，甚至它们两个根本就产生不了框架（那些所谓的CSS框架，在能力上和真正的程序框架差的太远了，我觉得顶多算是CSS模式[Pattern]）。要部分解决这个问题，我提倡用真正的程序语言，比如Velocity/PHP/Ruby等对HTML进行二次封装，实际上本站上面的很多东西就是靠helper（助手，MVC中View的一个组成部分，可以理解成帮助页面显示的一些程序）渲染出来的；
2. 系统逻辑太复杂，以至于顺利完成工作都变成了一个不小的挑战，更别说还管什么性能和质量了。写到这里想起曾经写过的一个control（控件，MVC中View的一个组成部分，可以理解成页面上的一个复用的元素），在当时紧张的时间里，control里面的代码质量已经算是不错的了（跟我搭档的几个Java程序员这么认为，其实我觉得一般，不过确实没时间写得更好了），可仍没办法做到把HTML、Javascript和Velocity代码完全分开，因为判断的逻辑太多太复杂。以至于在浏览器中看到的东西，比如一个小小的下拉菜单，它背后所隐藏的东西可能超乎想象。

第一季讲了如何消除用户的紧张感，这次说说如何挖掘用户的想法。

1. 划清楚你和产品的界线

首先告诉你的用户：你不是这个产品的设计者，甚至不是设计这个产品的公司，因此你不知道也不介意产品所存在的任何问题，你的工作就是收集上述问题。请他不要担心他的意见会有损任何人的面子，任何问题和意见都可以直言不讳。

要非常清楚地表明你自己和产品设计者的关系，尽可能地消除用户的戒备心。我有时会说：“你瞧，这里就我们两个人，没有某某公司的人在场（指产品设计者，殊不知他们正在观察室中紧张不安呢），所以不要紧张，也不用顾及面子。”

其次，在产品的试用过程中，当你提及产品时，切忌用“我们”，比如“我们还提供了这样一个功能”、“我们的设计初衷是……”等等，因为这会让用户觉得你和产品设计者是一伙儿的，抵消了刚才那番话的意义。我注意到，有相当一部分人在访谈时会不自觉的使用“我们”这一代词，这实际上不是个好做法。

最后，除了和产品划清界线以外，主持人和用户之间是否应有界线，我目前尚无定论。这个问题我和同事讨论过，如果主持人站在用户这边，好处可能是给用户的安全和认同感，坏处则是一不留神就会过度引导用户；如果主持人、用户和产品各自独立，好处可能是让用户更为客观，坏处则是可能会使其变得更为谨慎。对于这个问题，不知各位有何经验？

2. 搞明白测试的对象是产品而非用户，后者永远是对的

我会非常直接且明确地告诉对方，他永远是对的。请他来的目的，是想找出产品的问题并尝试改进，而绝对不是测试他的智商、或挑战他的使用习惯。

尽量不要用“测试”这个词，因为它有两个很明显的缺点：一是让用户觉得这是在测试他本人的智商；二是测试一般指产品研发尾声的步骤，更改的幅度不可能很大，既然如此，用户自然觉得自己的观点说了也是白说。

在访谈过程中，尽量给用户传达“这是早期的产品原型，可以很容易地做出修改”的概念，激发他去大胆想象，并把这些想象和平时的使用习惯理直气壮地说出来。

3. 做到无我：不可有观点，更不能表现出情绪

你是主持人，绝对不能有观点，更不能有任何情绪！这是访谈正式开始后，最为重要、且需要贯穿始终的原则。

那么如何做到这点呢？有以下方法可以遵循：

1. 用中性词替代褒贬义词，或者让褒贬义词成对出现
2. 慎用带有强烈感情色彩的词
3. 启发用户、并等待他的答案时，不要用列举去提示，否则会限制对方的思维，或者过度引导
4. 对任何用户的观点或产品的功能，不要做个人判断或表现出倾向性

4. 由简单问题开始，把需要仔细思考的留在后面

这是受了前同事的启发而来。以前在支付宝时参加过一个关于演讲/讲课的培训，培训的主持人红桃K告诉我们，在讲课时先讲特别简单的内容，听众一看你讲的都如此容易理解，就会立即放松下来。

我觉得这是个特别好的办法。如果用户觉得你的问题都比较容易回答、不那么可怕的话，他的精神才能放松，放松才能把掏心窝子的话说给你听。

当然如果你复杂的问题很多，你就要考虑把简单和复杂的问题错落安排了，否则连续回答复杂的问题会使用户疲惫，降低答案质量。

5. 保证和用户对各种概念具有同样的理解

同样一个词每个人的理解都不一样，尤其是那些解释很宽泛的词，比如“好”、“方便”和“舒服”等等，你的想法和用户的可能完全就是两回事儿。所以面对这些概念，必须要求用户去解释。比如对于一个“好”字来说，你可以问“‘好’是什么意思”、“为什么好”、“‘好’体现在哪里”、“哪些东西让你觉得好”等等一系列问题。

6. 变着法的问“为什么”

用户说的不一定是他想要的，这道理谁都懂，所以你要不停地问其原因，从答案中才能获得用户真正的想法。

有时候直接问“为什么”效果不一定好，那就换一种问法。比如“有哪些因素让你有某某感受（观点、想法）”等。一种问法不奏效，就再换一种，总之，想办法知其所以然。

还有一种方法就是让用户去比较。比如他觉得某个产品好可又说不出原因，你不妨各他另外一款同类型不同型号的产品，让他通过比较得出答案。

7. 面对谨慎中庸的人，就给他选项让他选

前文提到，我曾经遇到过一个极其谨慎小心的中年男子（40岁出头），其处事相当保守中庸，在整个访谈过程中自始至终没有说产品的一句坏话，每当使用起来出现问题时，便推说自己“不习惯、不适应、过一段时间就会好”一类的话。此外，他的逻辑思维能力比较弱，反应也非常慢，常常闷头操作不理会我的问题，搞得我很是郁闷。为了能挖出他的想法，我当时真是绞尽脑汁，疲惫至极，常常就忘了上一分钟准备好的问题。

这样年龄的用户一般不是互联网公司的典型用户，我没什么经验，处理起来感觉很是棘手。所以这条里面总结出来的东西不一定对，放出来权当抛砖引玉。

简言之，我对付他的办法就是：替他把话说出来，或者提供选项给他，然后请他确认或选择。

这样做好像有很大的干扰和引导，可是对于不喜欢张嘴的用户，还能怎么办呢？

8. 善用陷阱，让用户自相矛盾时暴露真正的想法

有的时候会遇到这样一种情况：用户认为的设计和现有的产品设计不同，可他又说不出自己为何会有如此设计（即使是变着法的探究原因也不行）。我就索性给用户设置一些小陷阱：引导用户按照他的逻辑合理地推论，直到他发现他的想法和产品的设计出现了矛盾（或者说，他同样的逻辑和想法，和产品的某些设计相符，某些相悖），此时他势必会想办法维护自己的观点，往往开始口若悬河地列举出你刚才没能挖掘出来的信息。另外，所谓言多必失，主持人此时仔细聆听用户的意见，一定会发现一些问题，顺着这些问题挖掘下去，便很有可能有意想不到的收获。

在为时一周的访谈中，我多次运用了这一技巧，感觉效果不错。

不过，这种方法可能存在一个很大的问题：用户很可能为了保护自己的面子，硬性地编造出理由来，这些理由显然并非是其原始的、真正的想法。这样一来就适得其反、事与愿违了。

那么，究竟该不该采用这种方法，采用的话如何避免上述问题发生，我和同事讨论了半天都没有一个答案，还是留给诸位吧。

9. 合理的启发用户，但不要教他

前面已经说过了，你不是也不应该是全知全能者，所以教用户如何使用产品绝对不是个好主意。

但当用户的想法明显不符合逻辑、并且你也知道了用户原始的想法后（比如我上次提到的那个不会用拖拽操作的用户），不妨进行合理的启发，并观察用户对你启发的反应。

10. 必要的时候，可以施加一些压力

此招慎用！偶尔有效，更多的时候，只会让用户在你的压力下说出编造的答案。

--------------迎偶晕，分割线这厢有礼了----------------

第二季到此结束，下一季中我想说说主持人常犯的错误，敬请期待。

上周做用户访谈的时候，发现一个关于隐喻的颇有意思的事情。

首先引起我对这个问题特别注意的，是一位不使用电脑的三十出头的女性，你没看错，她的确是不使用电脑！虽然她在访谈过程中间或拿出iPhone来打电话或发短信，但对她来说，iPhone的功能仅限于电话、短信和游戏。因此，在我们这些长期的电脑使用者看来理所当然的事，她却无法理解。比如说，她不知道UI上的拖拽（Drag and Drop）是怎么一回事，当我要求她完成一个拖拽任务时，她的做法是这样的：

• 先在要被移动的项目上按一下，意思是选中；
• 在目的区域那里按一下，然后等着那个项目自动地移动过去。

我不禁哑然！不明白为什么会有这样的思维方式，于是指着桌子上的铅笔问她：现实生活中把一个铅笔从桌子一端移动到另一端，使用上述方式是否可行？在得到否定答案后，我继续问道：那么为什么在电脑上就会有如此做法？她回答说：因为电脑和现实是不一样的！

你瞧，一个不使用电脑的人，对软件UI都有这样的认识，那么这到底是由于长期以来我们给用户以太多错误的隐喻，还是缘于用户对技术的恐惧呢？

后来我又遇到了一个对电脑比较熟悉的用户，他如预期那样没费什么力气就完成了拖拽任务，那么这是不是表示他的思维模型就没问题呢？不尽然，他能够完成这个操作，和下面任何一个原因都可能有关系：

• 他就是按照现实中的做法来拖拽的。这是最理想的答案；
• 长期以来的用户习惯，电脑中一贯是这样操作的；
• 以上两点都有可能－电脑中和现实中拖拽操作的隐喻恰好相符，都可以用直接操纵（Direct Manipulation）的方式进行。

那么，哪个答案最接近他的实际情况呢？从另外一个测试任务中可见端倪。

这是个图片缩放的任务。我们要求用户想办法缩放屏幕上的图片，测试预期是用户采用直接操纵（Direct Manipulation）来完成，当然这一预期对用户是保密的。

结果呢？用户开始后第一件事儿就是寻找缩放按钮！

这真是让我大跌眼镜，我原以为他会按照现实中的做法来做，可他却选择了另外一条路。我不由得想要探究原因（虽然这不属于测试计划），几经询问，得知他是出于使用习惯－电脑上看图软件中的缩放都是依靠按钮来完成的，久而久之习惯就成了自然。我请他试图回忆初次使用看图软件进行缩放的经历，他说：隐约记得屏幕上有个很明显的放大镜图标，于是在他思考如何缩放之前，这个图标就已经给他了先入为主的印象。

这两场访谈结束后，我一直在思考这个问题，并觉得：

虽然直接操纵将会是UI未来发展的一个主要方向，然而在其成为主流之前，我们－作为设计师－仍然有许多以前欠下的债要还。

连续做了一个星期的用户测试与访谈，工作强度很高，收获也不少，于是自然想到要及时总结；第三天遇到的都是逻辑思维不那么清楚的用户，尤其经历了与一个极为谨慎中庸的中年男性用户的访谈后，精疲力尽的我突然想到了“绝望主妇（Desperate Housewives）”，于是便有了“绝望主持人（Desperate Moderators）”这个名字。

“绝望主持人”预计会包括：1）如何消除用户的紧张感；2）如何挖掘到用户真正的想法。这次主要说说第一条。

1. 谈话中各自角色定位的技巧

什么叫“角色定位”呢？就是你如何确定你和用户各自在谈话中所扮演的角色、以及这两种角色的关系。

举例来说，在获得了用户的姓名后，主持人通常这样自我介绍：

“您好，我是今天这一产品试用活动的主持人，我叫XX。”

这句话看起来好像没什么问题，但在实际操作时，我发现它会给某些用户带来一定的压力，有些用户会由此认为他们理应由主持人去指引，使他们产生从属、甚至是上下级的感觉，并在其后的访谈过程中表现出小心与谨慎。在观察室作翻译工作的同事，对此和我有相同看法。

据我观察和猜测，此类用户在生活中较易追随他人的观点，相对而言缺乏主见与自信，习惯于在既定的事实和框架中调整自己、而非尝试改变外部环境。

那么，作为访谈主持人，在应对此类用户时，应尽量去突出用户的主体地位，弱化自己在访谈中所占的分量，比如用这样的说法：

“您好，我叫XX。今天主要由您来试用这些产品，并告诉我您的想法……”

2. 打开用户的话匣子

和用户聊聊他的工作，或者让他给你讲讲他自己熟悉的事情，是一个非常有效地让用户放松的办法。闲话天气我也试过，不过除了显得很傻以外，好像并没什么实际效果，当然也可能是我的方法不对。

简而言之，尽量让用户说些轻松并熟知的事情，可以更好地使用户面对陌生的环境。

3. 清晰简要地介绍访谈/测试过程，以消除因迷惑和担心而带来的紧张

或多或少，人总是对不确定的东西感到迷惑和担心。第一次参与此类活动的用户，面对陌生的主持人和即将试用的产品时更是如此。我发现有相当一部分人都担心自己因不能成功试用新产品而出丑，因此主持人一定要简明扼要的让用户明白，试用过程分为几个步骤、每个步骤需要做些什么，总共持续多久等等，帮助用户对试用和访谈过程产生预期，消除不确定的因素。

4. 还有……

请他喝水、吃零食，或者用纸巾擦擦汗，都是能让用户放松下来的小细节。写到这里突然想起来，有一名用户不知是因为过于紧张、天气炎热，抑或两者皆而有之，脸上可谓是大汗淋漓！我甚至一度担心他会不会因为鼻子上的汗珠掉下来而感到尴尬，当时我借口感叹外面的酷暑，把纸巾和水送到他面前，并转换到轻松和安静的话题上，过了好一阵子此用户才安稳下来。现在想来真是一段有趣的经历：）

这次就到这儿，下次的话题估计大家都会感兴趣：如何和用户斗智斗勇，把他心底里的想法挖出来。

我目前就职于Idean - 一家来自于芬兰的专业设计咨询公司。我们的服务涵盖手机（目前为主）、软件、网站和其它实物类领域。

我们现在需要经验丰富或者深具潜力的交互设计师加入，一起为了公司的口号“The Next Big Things”而奋斗！

详细的公司介绍和岗位说明可以见：

http://www.idean.com/jobs/iadesigners.html

现在是钱多人少！感兴趣的话千万别犹豫，即刻发简历给我（或者网页上面提到的Mr. Jesse Maula）。有问题请留言。

在国人还在忙着研究SVCD、CVD、EVD、威力棒（Vii）、M8和山寨机的时候，老外搞出了Cam-Trax：

昨天晚上支付宝主办了阿里巴巴集团内部的第三届“阿里巴巴D4设计论坛”，有几项内容比较有趣，想拿来讨论一番。

商业需求和用户需求是矛盾的

这种说法就好像“界面上文案多了用户不看”一样，成为了一个广泛传播却又尚未被证明的伪命题。

我个人并不十分赞同这种观点。持这种观点的设计师恐怕是受了太多运营部门的影响，而把商业和用户放在了互相对立的位置上－如果想最好的达到商业目标，就要牺牲用户利益，反之亦然。所以每次的产品/界面设计，都成了运营所代表的商业目标和产品所代表的用户利益之间的折中品，是两方各自妥协的产物。

淘宝的同事以当年著名的“淘宝广告弹窗事件”为例，说明“广告弹窗”这一商业目标由于给用户带来了极大不便，遭到了用户强烈的反对，最后不得不放弃这个商业目标而维护用户的利益和需求。

这样的说法问题在于，它往往混淆了“商业目标”和“具体方案”的概念。为了实现一个特定的商业目标，设计师完全可以设计出许多不同的方案，其中有好有坏，有的受用户喜欢有的遭来反对。最好的结果，当然是设计师的方案及满足了用户需求，又因此实现了商业目标。

成功的例子屡见不鲜。比如Sony的PS2、Apple的iPhone，它们往往在上市的前几天内就被抢购一空，提前完成了销售计划这一商业目标。由于出色的产品设计，用户的需求非常旺盛，商业目标自然而言就达成了。

有人可能会说：你举的例子都是商业目标本来就和用户需求相符，所以当然不会出现矛盾。那么对于本来没有用户需求的商业目标怎么办？我的答案是：创造需求。作出伟大的产品，激发用户的兴趣，通过给产品打上独特的（文化）烙印，让用户对这一烙印产生认同甚至崇拜。把这一点做到极致的公司如Porsche、Apple等。还有一种情况就是产品成功地挖掘出并满足了用户的潜在需求，比如Ford汽车的诞生。Ford汽车的创始人Ford曾说过一句非常著名的话：“如果我当年跑到大街上问用户需要什么，他们肯定会告诉我：‘一匹更快的马’！”

设计师的三种能力

阿里巴巴的同事Eric介绍说，Yahoo!的设计师认为一个成功的设计师应该具备三种能力，即People、Numbers和Process。

People包括1）了解内外部用户（Read people）；2）推销自己的观点（Be a salesman）；3）（Real-time performance）；4）Fight when you have to。

Numbers包括1）量化（Build in the metrics）；2）应用正确的方法决策（Justify decisions with the right kind of research）；3）不要过度研究（Don't over research）。

Process包括1）“平衡投入产出。不要过多去考虑和争论，有些方案可以先做出来，再看效果”（此翻译来源于Eric，原文为（Balance prep with implementation）；2）自下而上的策略（Bottom up strategy）；3）每个人都能成为设计专家（Everyone is a design expert）。

此外，这位同事还提到了设计师的职业规划问题，他所引述的观点认为，设计师以后可以朝产品经理的方向发展。在此我想听听大家的看法，你认为设计师以后的发展方向是什么呢？

丁宇，08年5月10日夜

其实4月29日早上就从北京回杭了，只是现在才抽出时间来记录这次短暂的旅行。

先说D2。

第一场讲座是周爱民先生带来的“前端设计与开发的基本模式”。周爱民的技术水平之高无须赘言，因此我对本场是非常期待的。听下来却发现演讲中纯粹的软件技术探讨不多，内容以UI设计为主，听软件技术专家讲UI设计倒是头一遭，并且其中有些观点确实是独辟蹊径，以另一种视角阐释了UI设计中的焦点、布局和分辨率的关系等问题，虽然也有相当部分有失偏颇（比如混淆了“视觉焦点”和“界面上所获得的焦点”的含义），但总的来讲仍能给UI从业者带来不少有益的思考。

演讲时周爱民问了个问题：GUI中的WIMP是什么意思？大概是问题太初级，没人好意思举手。我便说了句“Window、Icon、Menu和Pointing device”，结果就骗了本周大侠的新书（如下），哈！

第三场名为“Enterprise Ajax in PHP”。主讲人Hedger Wang一上来就提出了一大堆看起来相当吓人的名词，听着听着却发现，这不就是拥有一个Front-Controller的MVC加JSON嘛！不过既然作为专题讲出来，想必肯定是在此方面经验丰富。于是我提了个一直困扰我的问题：在一个拥有复杂交互的系统中（想象一个拥有几十个对话框的CRM系统），各种Ajax事件会非常多，此时如何管理这些事件就成了一个比较麻烦的事情。可惜可惜，看起来Hedger对这个问题也没什么经验。另外不知道是不是因为年轻气盛的缘故，Hedger给人一种盛气凌人的感觉，交谈起来很不舒服。并且当我听到他宣称Prototype和jQuery“不适合企业级应用”时，我也就没兴趣再问下去了。

有趣的是，我站在台上提问的照片，上了cnBeta（下图就是），哈哈！

最后一场是年轻有位的Yahoo!资深工程师章亦春带来的“Nifty web apps on an OpenResty”，因为有丰富的Perl经验和背景，章给我的感觉是新一代的Unix hacker。他的OpenResty框架能够让开发人员更关注于客户端（浏览器端）编程，而把服务器端变为一个单纯的API提供者和数据源。这个想法本身倒是不坏，我只是不明白其应用场景是怎样的，究竟是怎样的原始需求催生了这个框架呢？另外，OpenResty完全使用Javascript来CRUD数据，并操控各种浏览器行为，此时性能如何保障？可能由于时间的关系，章当时的回答并没有解决上述问题。

此外，OpenResty中的“Resty”表现在何处？这也是当时我没能领会的。从演讲时那个留言板的例子来看，在翻页时URL始终为http://server/path/to/posts.html（因为都是通过JSON来更新其中数据的），恐怕类似http://server/path/to/posts/page3.html这样的URL更加Rest化吧！章同学看到本文不妨解答一下 ：）

本届D2上虽然演讲数量不多，但质量都比较高。希望下届的D2能够以收费的形式来举办，以期进一步提升其素质。

今天使用我写的jQuery Countdown Plugin时，遇到一个特殊的需求：要停止正在进行的倒计时。

Google了一下，发现window.clearTimeout可以做这事儿，但要求首先获得window.setTimeout的句柄，我在写这个plugin时并没有考虑这点，又不想加个句柄变量到jQuery对象中，于是再度Google，并发现了一个window.clearTimeout的很奇怪的用法，可以自动获得句柄：

window.clearTimeout(setTimeout("0")-1);

这条语句确实能够满足我的需求，可我不明白这是什么意思，哪位高手能给解释下？

根据这个发现，我顺便更新了plugin－加了个stop()方法，详细用法和下载见这里。

此外一个有趣的现象就是：在IE和FF下，window.setTimeout返回的句柄不同。在IE下，它是一个8位的数字，并且每次刷新页面时这个数字以3递增；在FF下，它是个各位的数字，并且刷新时不会有变化。

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

先说架构组

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

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

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

再说用户研究组

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

最后说设计师组

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

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

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

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

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

另起一段，休息一下。

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

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

丁宇，08年3月25日夜