前言 用户体验支配一切

今天，用户体验（UX）是软件产品建立竞争优势的核心驱动力。体验不好的软件根本就卖不出去，硬件产品或者服务也一样。

打造良好的用户体验并不难，但是需要你建立起新的思考方式。本书将通过案例一步步来告诉你该怎么做。

你最强的优势

在如今的软件行业里，用户体验已经是建立竞争优势的核心驱动力。实际上无论你是设计并销售软件产品（如微软），还是提供硬件（Apple）或服务（UPS快递），用户体验的重要性都毋庸置疑。

就像“在公共场所吸烟”曾经是大家司空见惯的行为一样，以前的软件也总是把用户塞进一个五维扭曲空间里，把自己搞得晕头转向才能掌握它——用以前的话讲，就是要先成为“电脑达人”。UX大师Alan Cooper曾说过，这些“电脑达人”们“被软件虐了千百遍，伤疤都厚到感觉不到痛了”。用户也一度接受了这样的事实：这就是用电脑工作的代价。而现在，一切都改变了。

还记得1997年Apple濒临倒闭时的事情吗？最后它通过接受一笔来自微软（后者是为了避免垄断嫌疑）的现金注资才勉强维持了下来。而今天的Apple又如何成了这个星球上市值最高的公司？答案是超棒的用户体验，消费者愿意为了它付出更高的溢价。这就可以看出如今UX是多么重要。

对于企业用户，UX同样很关键。2014年12月，雅芳（Avon）公司不得不放弃了新版的订单管理软件。据《华尔街日报》报道，当时这家公司的独立销售代表们抱怨用新系统来处理日常销售工作太麻烦，太容易搞混了，以致最后纷纷离开了雅芳。

即使是IBM，这家曾被认为又乏味又笨重的大公司，近日也宣布会投入1亿美元在用户体验咨询业务方面，在全球范围内建立设计实验室，招募超过1000名新员工。

无论你在做什么，在为谁提供服务，你都需要提供杰出的用户体验。它不再是备选，而是必需。

UX不是选择字体和配色

有超多的开发者和管理人员都认为，用户体验设计就是在选择字体、配色方案，还有给按钮加上圆角什么的。大错特错！那些弹窗的圆角，还有可爱的动画，都是处于设计流程最后期的部分，也是最不重要的部分。我的同事——软件传奇人物Billy Hollis说它们“是装饰，而不是设计”。

那么，用户体验（UX）和用户界面（UI）之间的差异点到底在哪儿呢？就像所有那些在不同场景中会有不同解读的词汇一样，不同的作者对此也总有不同意见。在本书范围内，我用UI这个词特指在打造软件的过程中最后添加的装饰部分。而UX这个词，借用Jakob Nielsen和Donald Norman发表过的说法：“用户体验包含终端用户和一个公司，以及公司所提供的服务和软件打交道时的方方面面。”这就意味着任何可以被用户听到、看到、触摸到以及想到的都是UX：一个程序的工作流程，它提供的一套特性，它需要用户提供的输入，以及展示给用户的内容及其表现形式等。

图1描述了它们的区别。图1a展示了一个产品，假设这代表着你要用程序去完成的一项工作。图1b展示的是UI部分，你通过它来和这个产品做交互。图1c描述的是完整的用户体验，它是你和这个产品打交道时的过程。

通常，用户体验的竞赛在远未到达外观装饰阶段的时候就已经分出胜负了。把你的程序看作一件家具——比如说一张桌子。装饰就是它表层的漆面。当然，把桌子的漆面做得精细平整是很好的一件事情，你的软件也一样，但如果这个桌子选错了材料，不能满足用户的需要，那么它的漆面再精致也没用。如果你的用户想在家中采用了自然风格装修的客厅里摆放一个小桌，那么选用木质的桌子很可能合他的心意。而另一个用户，如果他需要给餐厅选购餐桌，每天都要频繁地清洁，那么金属材质会好得多。再退后一步看，你的用户真的需要一张桌子吗？是不是一把椅子就能更好地解决问题？

基础案例

我们通过一个实例来看看一些基础的开发决策是怎样成就或是搞砸UX的。之前我在瑞典教书时，当我用主域名“www.google.com”来打开Google首页时，它的服务器会检测位置来判断我所处的国家，并自动跳转到Google的瑞典版首页去（见图2）。对于大多数用户的大多数时间来说，这都是一个正确的选择，如果这不是你想要的，也只需一次点击（页面下方中间的链接）就能（通过保存Cookie）一劳永逸地搞定。

我们再来看看UPS.com——那家快递公司的首页（见图3）。UPS的首页需要用户自己先选择他们所处的国家和语言，要不然就什么事也做不了。如果你是瑞典人，那么大概需要30次点击才能搞定，读者可以感受一下。同时，你得明确地告诉网站记住你的偏好（看那个复选框），要不然下次还得再这么折腾一遍。它怎么能这样对待顾客呢？

这里面发生了什么？难道是因为Google的程序员比UPS的更聪明，才能检测出用户所处的国家吗？

当然不是。2014年，UPS.com最高峰时每天要处理超过一亿次的快递查询请求，他们的程序员必须足够优秀才能应对如此巨大的流量。这些天才程序员不可能不懂得如何检测每次访问的IP地址，然后推断出可能的位置和所处国家（这真的不难：一次简单的静态表查询，为了加速可以将结果加入缓存中，每天更新一次，搞定）。然而UPS最后却选择了让用户自己选择他们所处的国家，而不是自动检测。

在我看来，UPS在用户体验方面犯下大错：完全没有从用户的角度思考。做出这个决定的技术专家，表现得像一个典型的（包括我，还有你这样的）极客。我们被训练成了习惯数字化、逻辑化思考问题的人。从中学代数课开始就有了某种根深蒂固的想法：99%情况下准确，1%情况下不准确，那就不能称为定理。UPS不会去猜测你的位置，因为它有可能是错的。

对于一条数学定理，这样做没问题，但是对于活生生的用户这就不对了。和定理不同，如果你的应用能让99%的用户开心，那你就可以偷着笑了。同时，明天继续让这99%的用户开心可能比想办法迎合剩下的1%用户更重要，尤其是当后者的要求会给其他99%的人添麻烦的时候。当然这种理念在某个情景下不够理想，比如生活中的交通管制。但是对于大部分的商业和个人消费者场景来说，让主流情景无缝流畅，当特殊情景实际出现时再去处理都是更好的做法，而不是麻烦所有用户去做网站自己有能力并且应该去做的事情。

Google的语言检测算法也不是总能猜对。也许某个访问并不是真的来自瑞典；也许某个用户身在瑞典却不讲瑞典语（我）；又或者这个人就在瑞典，也会讲瑞典语，但是此刻他并不想使用这种语言（比如，一个瑞典的大学生正在练习英语）。但是做出最好的猜测，并允许用户修正错误，已经让主流用户群体大大获益。哪个公司的理念让你觉得它更尊重你的时间和精力？实际上，Google为用户想得更长远，以至于找到了识别UPS快递单号的方法。如果直接在Google的地址栏里面输入单号，Google就会直接给出这个包裹的配送追踪信息（图4），点击其中的链接，它会直接带你来到UPS网站上这个订单的详情页面，连语言都已经设定为正确的了。这就是我为什么总是用Google来查询UPS快递，而不是到UPS官网去自找麻烦，而我这样做的时候，总是忍不住面带微笑。

如你所见，这不是视觉设计的问题，完全不是。两个网站都有自己的logo、品牌配色和字体，以及独特的一切。但是其中一个网站强迫全部用户先要做无关的工作——让人头疼、分心，然后才能开始做他们来这里真正想做的事情——追踪快递进度。而另一个网站尽它最大的努力，直截了当地为大多数用户带来平滑流畅的体验，并在必要时允许用户修正错误。

两个网站的区别属于交互设计，有时候被称为行为设计，偶尔也被称为信息架构。这就是本书关注的。我们不会去探讨图形设计，也不会去讨论如何编程实现这些设计，已经有很多书涵盖这些主题了。我们将学习的是如何决定你要用代码实现的东西。而且我们会一直站在用户的这一边。

接访问UPS.com更简单

三条基本推论

我大学本科读的是物理学专业，现在我内心还保留着的一点物理学家因子总是让我坚持一件事，就是设定出基本原则，再从它们出发来判断对错。从Platt第一定律出发，我们可以引出下面三条推论。

● 推论一：你写的软件本身毫无价值。它唯一的价值，或可以有的价值，取决于在多大程度上可以让它的用户开心或更有效率。

● 推论二：软件以两种方式让用户开心或更有效率。首先，它能帮助用户解决一个特定问题——写一篇文章，支付一笔订单，或是给汽车导航。或者，它将用户带入一种愉悦的状态——欣赏音乐、玩游戏，或是和孙子孙女视频聊天。这就是可能存在的两种情形了，尽管有时候两种其实是掺杂在一起的。

● 推论三：上面的情形里用户并不愿去思考你的程序本身，完全不会。在第一种情形里，他们思考的是自己面对的问题：正在撰写的文档该选怎样的词汇，还有没有足够的钱来支付账单，哪个人的钱要是还不上结果会很惨。而后面的情形，用户只想尽快地进入状态，待在里面越久越好。任何耽误了他们解决问题，或是让他们在享受状态时分心的事情，都不会受欢迎，比在工作时被人打扰更甚。

让我们来总结一下三条推论：用户不关心你的程序，也不关心你本人。现在不会，以后也不会。你亲妈可能会，因为这程序是你写的而她很爱你，但也可能并不会。用户只关注他自己的效率或是感受。每个应用的每个用户都想要一台Donald Norman所说的“看不见的电脑”，就像同名书籍中描述的一样。

你可以看到，在前面的例子中，Google就在尽可能地隐藏自己，不像UPS那样。在心里记着Platt第一定律，还有它的三条推论，让我们一起看看另一个案例吧。

示例：要保存吗？

这是你每天都会遇到的状况。这简直可以说成了肌肉记忆，你都不会去想它。但是今天，让我们一起来思考一下。

在微软的Word软件里打开一个文档。敲上一些字或者修改一下，然后点关闭按钮。Word是怎么做的呢？它弹出一个对话框问道，“你想要保存修改吗？”（见图6）一位时尚的视觉设计师可以给“保存修改”对话框换上漂亮的字体，微妙的渐变色，当然还有精致的圆角。但是他没有也不能指出这个问题：这个程序应该像现在这样在用户退出时发出提问，还是应该像微软的OneNote一样在修改发生时就自动保存？哪一种方案会让用户更有效率、更开心？问题回到我们交互设计师这儿了，来做一个决定吧。应该如何选择？

让我们从一道算术题开始。Word在每次关闭的时候要求你做一个选择，然后点一次鼠标。如果用户做了100次修改，那他就要做100次选择，点100次鼠标。如果我们采用了自动保存方案，需要在界面找一个其他地方加入某种版本回滚的功能——比如说在编辑菜单里加上一项“放弃当前文件本次所有修改”，可能会需要5次点击来完成。如果99%的情况下用户想要保存修改，自动保存就可以把100次点击砍掉95次，大大减轻了用户的负担。如果只有50%的情况用户想要保存修改，那么自动保存实际上会增加用户的负担——100次点击骤增到了250次。你的程序又该如何选择呢？

和平时一样，这要分情况。在Word中你想要保存修改的频率有多高？或者换一种方式来看：把文件改得一团糟以至于想要点击“不保存”放弃修改的频率有多高？

你的用户保存修改的频率，相比他们放弃修改的频率孰高孰低呢？这又是完全不一样的问题了。我猜你想说：“好吧，我从来没见过他们要放弃修改。”和之前一样，这其实是你按自己的偏好说的话。你会发现很难不把自己带入进去。在潜意识里你是抵触“你的用户和你自己不一样”这种概念的。那么该怎么做呢？

你可以试着直接向真正的用户提问，如果能找到他们的话。如果你在自己公司的开发团队工作，打造一个面向内部使用的程序，这样做完全没问题。走上楼到用户面前提问就是了。然而，这种做法总是会遇到阻碍。这些用户想要和你谈话吗？他们能不能精确地回忆起细节？他们会不会怕别人笑话而不能敞开心扉？他们的老板是否同意占用他们的工作时间？和真实用户交谈是一个很好的开始。第1章和第3章会讨论通过这种渠道提取信息的各种方法。但你不是总能获得这种机会。

如果你在一个乙方公司的开发团队，也就是说，你是为一个外部客户开发软件，问题就更复杂了。假设你在办公室里找到一些人。你的同事，也就是那些每一天都在开发软件来卖的人。他们和你的产品用户群体类似吗？除非你在做的产品是一个软件开发工具。无论他们怎么说，都可能会误导你。微软在这个地方已经摔倒好多次了。

那么怎样才能知道有多大比例的用户想要保存修改呢？这可不是透过水晶球用神秘的读心术而是用远程数据监测技术收集大量用户的数据。第5章会解释远程数据监测的更多细节。你也可以邀请用户在早期来实验室做一些可用性测试，如第4章所述。

考虑用户体验，从第一刻开始

我见过许多公司总在犯同一个错误，就是没有从项目的初始阶段就开始考虑和计划用户体验。“我们要先尽快推出产品，然后再考虑它长什么样。”这简直是疯了。这就好像建筑师在建造房子的时候说：“我们得先把供暖和管道系统安装到位，再去想谁会住在这里。”你是在为一对老年夫妇盖房子吗？那应该在底层设置一个带浴缸的卫生间，有宽宽的门，还可能要安装几个扶栏。如果是有两个孩子的一对年轻夫妇，他们可能还计划着再生4个宝宝呢！问题就完全不一样了。对于将要去建造的房子，你不会在还没搞清楚最基本的细节之前就花掉开发预算开始施工。用户体验就是用来搞清楚这些的。

在之前的例子里，你会看到用户体验设计决定着你应该写怎样的代码，不只是表层的用户交互，而是深入到底层实现。再次以Word为例，整个撤销特性的实现机制取决于用户体验设计对于什么时机保存、如何保存文件这些命题做出了怎样的决定。在前面Google对比UPS的例子里，网站首页的开发者需要明确在他们写的代码运行的时候，是否已经获取到用户所在国家的信息（Google），或是他们需要从用户那里获取这些信息，然后传递到其他代码部分来使用（UPS）。

好的用户体验设计是从项目启动的那一刻就开始了。它不仅仅存在于表层，而是渗透在程序的每一个层面上，就像一个人的性格和荣誉感一样。而且在程序开发的每一个阶段你都需要注意它，不对，是在程序的整个生命周期里，就像是在一个人的一生中，性格和荣誉感都需要被关注一样。

客户有时在产品发布的最后时刻找到我，让我对用户体验做出评价。这时已经太晚而无济于事了。架构已经设定，预算已经花完，心态已经固化。读者要以此为戒。

为什么开发者总是不大考虑用户体验

当用户面对一台电脑不知道该怎么用，或是需要参加高价培训后才能学会，又或是被它上面的软件误导做错了事情、付出了昂贵的代价时，那么这台电脑对这个用户来说就只是一个昂贵的镇纸（废物）了。仍然有很多程序员和架构师觉得他们不用去操心用户体验。下面我们来看看他们为什么会这样说，以及为什么他们都错了。

1．我们的项目是比较底层的，所以用户体验无所谓

无稽之谈。每个项目都和人有着种种联系。就算是一个面向开发场景的Web服务，也需要错误报告、安装和配置、状态和性能监控的报表页（dashboard）等。如果一个项目只有很少量的用户体验工作，那就更应该去把这些部分做好。在20年前，你可能看到过这样的一个对话框跳出来说，“网络服务错误，错误代码20。查看文档获得更多信息。”今天如果你看到谁发布了这样的产品，你一定会笑出声来。

2．市场部决定着我们的用户体验

跟市场部搞好关系是很明智的。他们当然会感知到用户的痛点，并反馈到你这里。但同时，这些做市场营销的人并不是交互设计师。关于怎样才能让用户更开心、更高效，他们也许能给出一点线索——“客户在抱怨只要我们的程序一崩溃，他们编辑到一半的工作内容就全丢了。”——但是后面该怎么做是由你决定的。这样的事情多久发生一次？你该如何检测和记录它？解决这个问题的方案是：自动保存？提供回滚？用怎样的频率？允许用户自己配置吗？把这些问题抛给市场营销团队，你觉得他们真的能驱动用户体验吗？他们不行，你可以。即使是他们先拉响了警报。

同时你也应该和技术支持部门的人聊聊。比起市场部的人，用户把不满更早也更不留情面地先告诉了他们。

3．我们有用户体验小组去管那些事

有些大公司里会有一个用户体验小组来处理每一项用户交互。如果你们那里有，你可能已经发现了，他们的时间总是排得很紧，就像那些眼科医生一样。你可能求了他们6个月，才能约到一次15分钟的会面。他们没法帮你去追踪和迭代。你得自己去消化理解他们在这有限的交流里阐述的原则，并在每天的日常工作中去实践。

同时，他们的时间（非常客观地讲）总是贡献给你们公司最重要的对外产品的。他们没有时间去管那些内部使用的或是第二梯队的应用。拥有这种小组的公司重视良好的用户体验，你在参与的应用也被寄予厚望，然而你的老板并不会给你们提供对应的技能栈或资源来实现这种期望，不是吗？你得从项目团队层面准备好自己来做这些工作。

4．用户体验设计是艺术家做的事情

那些被称为视觉设计师的人，其实更准确的说法是装潢工。我们已经知道，用户体验的游戏在到达这一步之前就已经分出胜负了。对他们保持友好，但主战场不是他们的，是我们自己的。

从哪里获得这些技能

准确地说，因为贯穿项目的整个开发流程都需要关注用户体验，你的团队中需要有一个具备体验设计技能的人。这个人知道在文档保存的例子中如果要做出正确的决定，不能依赖个人的品味或是哲学理念，而是源自实际的用户数据——了解有多大比例的文档会被用户丢弃而不是保存。并且，她应该知道如何获取这些数据，理想状况下是从程序直接获取，如果不能实现就通过专业的访谈或观察进行。我们从哪里能找到这样的人呢？又该怎么管理他们？

普通的程序员、极客不知道该怎么做，他们错误地认为用户跟他们差不多，他们做出来的用户体验设计会和Visual Studio差不多。有时候市场部门的人想插手来做，认为自己和用户经常打交道所以了解用户的需求。这就好比你因为自己长了牙，就认为自己可以去补牙了。视觉设计师也想加入，但你知道，这种交互设计问题跟图形没什么关系。怎样才能找到我们需要的人？

让我们看一下美军，特别是它的最小单位——步兵排。一个排通常由一名少尉、一名经验丰富的第一中士，以及大概30名战士组成。另外每个排还会有一名医护兵。医护兵并不是具备完整资质的医生，尽管战士们习惯叫他“医生”。军队没办法给每个排都安插一名医生。医护兵经过训练，可以初步为伤员干预和稳定伤情——止血、注射、恢复呼吸等。在今天的战场上，能够在第一时间提供干预措施，是保证伤员存活的重要链条上的第一个环节。

我们在用户体验这件事上需要的角色就类似于医护兵。一个人了解基本的用户体验设计概念，以及常见的实践——比如知道数据是大多数用户体验问题的关键，知道如何获取这些数据。有些人还知道怎么快速、准确地生成用户画像，以便设计小组能够快速地抓住谁才是（容易被曲解的）“用户”。有些人也知道如何又快又低成本地做可用性测试，以确保项目不会因此暂停下来，或是应该直接跳过这些测试。关键点就是快速地给出用户体验问题的答案。就像医护兵一样，关键在于黄金时间施救。

有时候在一个重视用户体验并拥有一个想要控制一切细节的体验设计小组的公司里，这种关于医护兵的概念并不被买账。回到军队的场景里，这些人就是待在后方医院里的职业外科医生。如果你的方式正确，这些人其实是在团队里安插UX医护兵这件事中最大的受益者，比如，当他们被叫来评估那些谜之数据的时候，第一轮的可用性测试结果已经摆在他们面前。

你做得到

我的读者和学生跟我讲，实践优秀的用户体验，最难的部分就是不知道从哪里入手。人们总是经不起诱惑想要直接动手去做开发——OK，我们接下了这个项目，项目排期很紧（总是很紧的），我们开始做吧。No，别浪费时间搞什么用户画像了，我们得保持进度。用户故事？那是什么？别管了，打开Visual Studio就开始做。直接拿来控件摆放拖弄一番，要不要在这里放一个复选框或者是单选按钮？用一组tab标签怎么样？

回想我打开《The Joy of Cooking》那本书时的情形（本书英文版命名为《The Joy of UX》的灵感就是从这里来的），那本书是写给那些完全没有做饭经验的读者的，它的前言部分名为“站在炉子面前”——这也是我写这本书的方法，为了让你能从零开始。

在这篇前言之后，会有7章分别用来介绍打造优秀用户体验的7个步骤。每一章会介绍用户体验设计的一个特定技能。我是按照自己的实践经验来安排顺序的，你将看到，其中还会有一些回溯和迭代。如果你跟着这些步骤循序渐进地走下去，最终一定会有很好的收获，至少比随意翻开一章然后跳着翻看要好得多。按我一贯的谦虚做法，我把这称作Platt UX协议。

第8章和第9章会分别展示一个学习案例，从头到尾地实践7个步骤。我将介绍用户画像、用户故事、草图绘制、用户测试、远程数据监测、安全和隐私，以及最后的简化。我的学生告诉我，这种端到端的讨论能将不同的碎片拼接在一起，是课程中他们最喜欢的部分。

下面是每章将要涵盖的内容。

● 第1章：我们将学习并理解谁才是真正的用户。用户是男生还是女生，年轻人还是老人，高收入还是低收入？教育类型和级别？他们希望的是什么，又害怕什么？我们以用户画像的形式将这些问题记录下来，形成一个虚构的人来代表我们的用户群体。

● 第2章：我们将要了解用户使用我们软件的动机，以及他们实际是怎么使用的。他们想要解决什么问题，还是想要维持什么样的良好状态？好的解决方案或是感觉良好的状态有什么特征？我们从用户的视角，以用户故事的形式来阐述这些信息。（如果你对于敏捷开发概念中的用户故事很熟悉，会发现这里说的是另一个东西。）

● 第3章：我们了解了用户是谁以及他们的需求，现在，开始绘制一些可能的解决方案。用一个低保真绘制工具（本书选择了Balsamiq），我们可以快速地做出效果图，然后就可以拿它来测试、优化，开始一系列迭代了。

● 第4章：我们用效果图演示了可能的解决方案，现在就来测试它们。选择真实用户再理想不过，但是如果做不到的话用可以模拟和替代真实用户的测试者也行。我们给用户测试的产品拟真程度也取决于项目的阶段，在整个开发过程中，步骤3和步骤4会持续多轮。

● 第5章：我们计划给产品添加某些远程数据监测，以了解用户群体是怎么实际使用产品的。我们将会了解哪个特性是他们实际在用的，顺序是什么，还有他们使用的硬件是什么样的。在今天的大环境下，不使用数据监测，就如同在看病诊疗的过程中不用X射线或其他设备做检查一样。

● 第6章：安全性和易用性经常被认为水火不相容。在这一章，我们会仔细查看两者之间的交集，去理解当它们出问题时到底发生了什么。我们会形成一项尽可能严密的程序安全保障计划，同时让软件保持可用、易用。

● 第7章：在接近发布产品的时候，我们不该去添加特性，而是要去想办法降低目前已经提供的特性的使用成本。这是我们对程序的最后打磨。

● 第8章：我们将通过前面的完整步骤，为波士顿的通勤铁路系统设计一款全新的移动应用。

● 第9章：我们将通过前面的完整步骤，为波士顿地区的一家医院设计一款全新的供病人端使用的网站。

本书网站

本书和世界上其他东西一样，有它自己的官网JoyOfUX.com。图7展示了它的截图。

在这个网站上你可以看到本书提及的一些资源，比如用户画像的模板。我还会增加一些案例，与本书结尾的两篇类似。所以过上一两个月就来看看吧。另外如果你也有一个案例想要贡献出来，我将非常高兴。

本书相关资源也可登录华章网站www.hzbook.com下载。

让我们开始吧！

Arlo Guthrie在一首歌中唱到：一个人做，人们认为他疯了。三个人做，人们认为这是一个组织。如果50个人一起做，人们就知道这是一场运动了。

我希望对不好体验的反抗也能达到这样的目标。那么让我们开始吧。