用户体验是一种态度

 

近些年来，用户体验（User Experience，UX/UE）被提及得越来越频繁，无论是软件、IT 还是任何其他行业都开始日益重视用户体验，例如：

• 成立专门的用户体验部门/小组
• 新增与用户体验相关的专职设计师、工程师甚至高层管理人员
• 引入与用户体验相关的新开发设计流程
• 用户体验以需求或主要评价指标的形式单独出现

这场用户体验革命的浪潮让几乎所有人都意识到了重视用户体验的意义以及带来的价值，但在实践过程中，人们也发现它对传统的软件开发产生着巨大的冲击。很容易可以找出在企业或者产品团队中用户体验设计人员与开发人员之间的矛盾与对抗：

 

设计人员认为开发人员认为

• 开发人员不理解用户的需求
• 开发人员总是从程序的结构角度来考虑问题
• 开发人员总是用性能或者其他各式理由来拒绝一些设计上的要求
• 开发人员不愿意把时间花在进一步提升用户体验上

• 设计人员对技术一窍不通
• 设计人员的想法经常是天马行空、不切实际
• 设计人员总是喜欢标新立异，用户根本不习惯这些怪异的设计
• 设计人员的设计复杂度远远超出了项目初期的预算，我们根本不可能按时交付

在这些“抱怨”中我们可以注意到，最主要的矛盾在于设计人员和开发人员往往不能理解对方的工作内容，能够在对方知识背景方面有深厚积累的更是凤毛麟角。也正是因为这一点，很多产品经理（PM）并不能很好地对设计和开发进行权衡，使得很多决策必须通过设计人员与开发人员的反复“对抗”来进行。无疑，不管是团队内部的人员关系还是配合效率都有严重的负面影响。

 

是主导还是妥协？

 

一山不容二虎。如果设计人员和开发人员都各行其主张，产品永远无法不可能被开发出来。为了提升用户体验的地位，或者说是为了引入更加“用户体验”的开发设计流程，一些原本是“开发驱动”的流程开始转向“用户体验驱动（UX-driven）”。用户体验驱动的本意可能是强调“用户体验的重要性”，避免用户体验处于被动地位。对于强调“以用户为中心（User-Centered Design，UCD）”的开发流程中，更是起到了保障的作用。

 

勿容置疑，用户体验驱动开发确实提升了用户体验设计的主动性，但是遗憾的是：用户体验仍然是最终做出让步的一方。通俗地说，虽然现如今设计人员有了软件设计的主动权（而不是被动根据开发的要求进行设计支持），但是开发人员仍然可以（而且应当）拒绝一切在技术和资源上不合理或者不切实际的设计。如果设计妥协，产品只是不太好用而已；如果技术妥协，产品根本无法开发。一旦到了需要权衡的时候，牺牲的只能是用户体验。任何所谓“设计高于技术”的信条，只是市场宣传的一套说辞和吸引公众的口号罢了：没有哪一个企业能够容忍自己的产品开发永远处于未知状态。

 

所以，作为企业来说，只有商业驱动，没有技术驱动，更没有用户体验驱动。

 

是研发还是开发？

很多企业在这一点上界定并不明确，这里列出“研发”和“开发”的一些主要区别：

 

研发开发

• 创新、探索式的
• 以得到某项数据或者实现某项新技术为目标
• 没有严格的时间限制，往往是长期的
• 研究失败是正常的、可以接受的

• 项目工程式的
• 以生产制造某项产品为目标
• 有明确的时间限制和详细的开发计划
• 非市场因素造成的失败会被视为严重事故

一般来说，产品开发人员不会把“研发一项新技术”写进产品开发的需求列表，因为他们很清楚无法进行这样的规划和预算，他们也不会承诺在产品中实现某项目前还不存在或者没有掌握的技术——这是新技术实验室的研究人员做的事情。产品团队在制订开发计划时，只会选用现有的技术，因为只有这样，才能最大限制地保证在给定的时间范围内，用给定的资源完成项目开发。谁知道新技术猴年马月才能被研发出来呢？

 

不过，这一切在引入了用户体验设计之后就被打破了。“更好的用户体验”进入了产品开发的需求范围，用户体验设计人员并不是利用现成的技术在生产产品，而被要求进行“创新”。设计人员在几乎没有约束的状态下进行用户体验研发（而非开发），项目范围（scope）和工作量都处于严重模糊甚至失控的状态。开发人员不知道设计人员设计出来的软件需要多少工作量来“生产”，甚至往往连设计人员都无法预计自己的工作量。

 

是技术还是态度？

现在一提到“以用户为中心”，大家都会联想到用户体验的一套研究设计方法流程。但是如果提到“用户导向”这个概念，可能大家已经习以为常。对于以商业为目的的企业活动来说，我（至少目前）并不觉得这两个概念有什么区别，只不过前者听起来更加亲切，后者的学术感更强而已。“客户至上”“顾客就是上帝”“顾客永远是对的”这些口号无一不在反映着“以用户为中心”的根本思想。很多年前，市场营销学家们就提出了变“生产导向”为“市场导向”，后又将“市场导向”重新表述为“用户导向”。但是无论是哪种导向，市场营销还是市场营销，客服还是客服，并没有让用户体验团队来取代他们的职责。对于各种职能部门来说，无论是“用户导向”还是“以用户为中心”都是一种理念，一种新的思维方式，而不是新的技术。

 

回到软件开发行业。最早的软件开发就是编码，能把程序写出来就万事大吉——那个时候可以算是“功能导向”的。当软件规模越来越大时，这种随意的开发不再适合，于是开始有人研究软件开发的工程化，出现了面向软件开发的流程管理和质量控制，形成了软件工程体系。这一阶段，软件内部的质量有了明显的提高，开发过程的质量也得到了控制。当“生产导向”变成“市场导向”时，软件开发商不得不开始重视用户对软件的感受，于是开始试图提升“软件面向最终用户的质量”，也就是我们常说的“用户体验”。

 

在用户眼中，一切都是用户体验。无论是软件的界面美观性、可用性、说明书的装订、包装盒的印刷、杂志广告的内容、还是销售和客服人员的服务态度等等，都是用户体验的范畴。用户体验部门如果对于界面设计事事具细，理应对生产印刷、物流、广告、售前售后等都应进行详尽的设计和规范。但事实上又没有哪个组织的用户体验部门能够如此“全能”。因此，在我看来，无论是说“用户体验”还是说“以用户为中心”，都不是在指具体的技术或职能，更多的是一种工作态度，就和认真仔细、耐心、热情、有责任心等等方面一样，是一种横跨所有技能职位的行事态度。换句话说：要做 UX 的人，而不是 UX 的事。

 

如何发挥用户体验的价值？

经过之前三个方面的讨论，现在应该来说说用户体验以及用户体验团队应该如何更好地在 IT 企业中发挥价值。

 

首先，“以用户为中心”是一种理念，“关注用户体验”是企业每个部门每个岗位的责任，而不只是专职人员的工作。也正因为如此，用户体验部门的主要职能不再是细节的界面设计，而是对整个公司各项活动进行宏观指导和规范，以整体提高每个环节的用户体验。此时的用户体验部门不再是一个垂直部门，而是变为横向部门。

 

其次，原来的那些事情还是需要人来做的，比如信息架构设计、交互设计、视觉设计、用户研究、可用性测试等等。这些职能仍然需要相关的专职人员，但不再属于用户体验部门，而是根据其具体的业务对象，回归各个部门的职能。就好像开发需要前端、后台、测试工程师等等一样，需求工程师、交互设计师、视觉设计师、可用性测试工程师也是开发团队中的职能，没有必要非要用“用户体验部门”将其独立和分离，更不可与开发团队并行。至于用户研究人员则可以回归市场营销部门。在一个完整的产品小组中，各职能人员是在 PM 的带领下协同工作，而不是某部分去“驱动”另外的部分。真正的用户体验部门则应当制订更好的跨部门工作流程并给予各部门专业指导，以保证大家确实是在“以用户为中心”的方式工作。

 

最后，也是最重要的：研发与开发的分离。用户的反馈收集与研究、用户体验的提升、交互方式改进等等应当是研发的范畴，由研发部门进行。产品部门要做的仅仅是从研发部门中选取适合自己的研究成果，并把一些问题和想法提给研发部门——而绝不是在产品开发过程中给研发部门下达计划任务。用户体验设计从根本上来说是一种创新活动，而在产品开发过程中是很难做到充分创新的，因此用户体验设计应当放入科研轨道。更彻底的做法是：即使是在研发团队中，用户体验设计也应当只是研发团队的一部分，研发团队向其他部门输出的不能只是空洞的“创意”和“想法”，而必须是经过技术研发的、可行的“解决方案”，保证产品开发团队只需要“拿来主义”。只有这样，才能让科研人员没有束缚地不断追求更好的用户体验并将其付诸于实现，而产品团队也不至于对产品需求、范围和工期难以掌控导致项目延期甚至失败。

 

当然，要建立这样的体系需要强大的资金支持。追求好的用户体验与实现好的传统软件工程一样，都需要组织自身的积累和支撑。对于实力并不雄厚的小企业来说，除了发挥英雄主义之外，还有很长的路要走。

 

 

（原文发表于：http://www.richardbao.com/diary/entry.aspx?id=72E3F2F501A68A9!1412）