心弦

昨天晚上支付宝主办了阿里巴巴集团内部的第三届“阿里巴巴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日夜

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

写了一个简单的倒计时（countdown）插件，用法非常简单：

上例中，这个插件会在div.countdown中插入3秒钟的倒计时，直到0为止并调用helloWorld()这个函数。

这个插件有两个选项：

• seconds - 从多少秒开始倒计时；
• callback - 可选，倒计时结束时执行的回调函数。

目前的版本是0.2，下载地址如下：

• jquery.countdown.js，2kb
• jquery.countdown.min.js，1kb

更新记录：

0.2。加入了stop()方法，可以停止一个正在进行中的倒计时。