一本帮助开发者打造世界级用户体验的完全实践指南
涵盖完整的设计流程，从用户画像、用户故事到草图绘制、布局以及执行阶段
Steve Krug，《点石成金:访客至上的Web和移动可用性设计秘笈》作者
多年以来，我四处奔走，向每位愿意聆听的人传播“人人（而不只是专业的体验设计师）都该关注用户体验”的理念。在向开发者解释“用户体验应该关注什么”这件事上，David 通过完整而紧凑、容易被吸收并能马上付诸实践的形式，做出了伟大的工作。开发者们，请来带走这本书！
阮一峰，《软件随想录》、《黑客与画家》的译者，《ES6 标准入门》的作者
一种软件产品能够脱颖而出，用户体验往往是关键。本书通过大量案例，帮助你领会如何提升用户体验，可以作为你学习 UX 设计的第一本书。作者重视细节，耐心讲解实现方法，内容具有可操作性。
JJ Ying，百度MUX上海设计团队负责人， 著名设计类播客 Anyway.FM 主播
经常有刚入行的设计师问我应该看哪些书来入门，我一直很难给出一个完整的书目，因为 UX 这个课题非常大，所跨专业也非常广，但《用户体验乐趣多》这本书让我眼前一亮。作者的写作思路和受众都是偏向软件开发者的，所以全书非常贴近真实产品和实际工作，通过数量众多和极其细致的案例分析，相信能帮助读者们对 UX 行业的各种概念有深入的理解。
高质量的用户体验并不难达成，但它确实需要开发者用新的方式来思考。本书将通过具体的案例来告诉你该怎么做，会帮助你在面临技术困难、工期紧迫、预算紧张等挑战时，优化产品的可用性和参与感。
作者简介
David Platt
通过自己的公司 Rolling Thunder Computing，在哈佛继续教育学院以及世界上很多公司内部教授 “用户体验工程” 和 “Microsoft .NET 编程” 课程。除本书外，他还写了11本编程相关书籍，其中包括《Why Software Sucks》以及《Introducing Microsoft .NET,Third Edition》。微软在2002年为他授予 “软件传奇人物” 称号。
译者简介
杨少波
曾在 Ubisoft、酷盘、阿里巴巴任资深交互设计师，现供职于 ThoughtWorks。地理信息系统专业毕业，由兴趣指引入行，被同事戏称为“披着设计师外皮的工程师”。如今年过三十，有了新的 title—— “小游的爸爸”，依然把 “打造让自己骄傲的、有意义的产品” 视为工作最大的乐趣。
阅读是打开新世界的一种方式，希望你在本书中找到乐趣。可以来微博（weibo.com/jimmy143）或是微信（yangshaobo1228）和我一起讨论。
作者简介
David Platt
通过自己的公司 Rolling Thunder Computing，在哈佛继续教育学院以及世界上很多公司内部教授 “用户体验工程” 和 “Microsoft .NET 编程” 课程。除本书外，他还写了11本编程相关书籍，其中包括《Why Software Sucks》以及《Introducing Microsoft .NET,Third Edition》。微软在2002年为他授予 “软件传奇人物” 称号。
在如今的软件行业里，用户体验已经是建立竞争优势的核心驱动力。没有优秀的用户体验，你的软件就会失败，硬件产品或服务也一样。打造良好的用户体验并不难，但是需要你建立起新的思考方式。本书就是一步步通过案例来告诉你该怎么做的。
本书从开发者视角，全方位阐释用户体验设计的相关概念、技术及最佳实践，覆盖完整的设计流程，从用户画像、用户故事到草图绘制、布局以及执行阶段。同时，本书还指出了一些在其他用户体验指南中常常被忽略的关键问题，比如远程数据监测和隐私安全等。通过本书，你还能找到所需的全部资源和工具：完整的案例分析、设计文档示例、用户测试计划表等。
全书共9章，前7章分别介绍打造优秀用户体验的七个步骤，每一章会介绍用户体验设计的一个特定技能，第8章和第9章分别通过完整的学习案例，从头至尾地实践七个步骤。通过阅读本书，你将从零开始，实践优秀的用户体验。
用户体验支配一切
今天，用户体验（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描述的是完整的用户体验，它是你和这个产品打交道时的过程。
图1 a）产品；b）用户界面；c）用户体验（来自Ed Lea, 产品设计师）
通常，用户体验的竞赛在远未到达外观装饰阶段的时候就已经分出胜负了。把你的程序看作一件家具—比如说一张桌子。装饰就是它表层的漆面。当然，把桌子的漆面做得精细平整是很好的一件事情，你的软件也一样，但如果这个桌子选错了材料，不能满足用户的需要，那么它的漆面再精致也没用。如果你的用户想在家中采用了自然风格装修的客厅里摆放一个小桌，那么选用木质的桌子很可能合他的心意。而另一个用户，如果他需要给餐厅选购餐桌，每天都要频繁地清洁，那么金属材质会好得多。再退后一步看，你的用户真的需要一张桌子吗？是不是一把椅子就能更好地解决问题？
基础案例
我们通过一个实例来看看一些基础的开发决策是怎样成就或是搞砸 UX 的。之前我在瑞典教书时，当我用主域名“www.google.com”来打开 Google 首页时，它的服务器会检测位置来判断我所处的国家，并自动跳转到 Google 的瑞典版首页去（见图2）。对于大多数用户的大多数时间来说，这都是一个正确的选择，如果这不是你想要的，也只需一次点击（页面下方中间的链接）就能（通过保存Cookie）一劳永逸地搞定。
图2 在瑞典打开的 Google 首页
我们再来看看UPS.com—那家快递公司的首页（见图3）。UPS 的首页需要用户自己先选择他们所处的国家和语言，要不然就什么事也做不了。如果你是瑞典人，那么大概需要30次点击才能搞定，读者可以感受一下。同时，你得明确地告诉网站记住你的偏好（看那个复选框），要不然下次还得再这么折腾一遍。它怎么能这样对待顾客呢？
图3 在瑞典打开的UPS首页
这里面发生了什么？难道是因为 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 官网去自找麻烦，而我这样做的时候，总是忍不住面带微笑。
图4 Google 自动识别出UPS的快递单号，并提供详情链接
如你所见，这不是视觉设计的问题，完全不是。两个网站都有自己的logo、品牌配色和字体，以及独特的一切。但是其中一个网站强迫全部用户先要做无关的工作—让人头疼、分心，然后才能开始做他们来这里真正想做的事情—追踪快递进度。而另一个网站尽它最大的努力，直截了当地为大多数用户带来平滑流畅的体验，并在必要时允许用户修正错误。
两个网站的区别属于交互设计，有时候被称为行为设计，偶尔也被称为信息架构。这就是本书关注的。我们不会去探讨图形设计，也不会去讨论如何编程实现这些设计，已经有很多书涵盖这些主题了。我们将学习的是如何决定你要用代码实现的东西。而且我们会一直站在用户的这一边。
图5 用Google 打开UPS订单详情页面时，自动匹配了用户浏览器使用的语言—比直接访问 UPS.com 更简单
Platt（作者）的第一条、最后一条，也是唯一一条用户体验设计定律
《塔木德经》中讲到，一个没耐性的人走到著名的犹太大师希列（Hillel）面前说：“我现在单脚站在地上，在我支撑不住之前，把《妥拉》（希伯来圣经最初的五部经典）的精髓教给我，”希列答道，“己所不欲，勿施于人。其他的都是对这句话的注解，去学吧。”你想要了解学习用户体验的诀窍吗？我的回答就一句话，它是我的第一条、最后一条，也是唯一一条用户体验设计定律：
去了解你的用户，因为他不是你。
剩下的都是对这句话的注解，我的朋友。来跟我一起学习吧。
三条基本推论
我大学本科读的是物理学专业，现在我内心还保留着的一点物理学家因子总是让我坚持一件事，就是设定出基本原则，再从它们出发来判断对错。从Platt第一定律出发，我们可以引出下面三条推论。
推论一：你写的软件本身毫无价值。它唯一的价值，或可以有的价值，取决于在多大程度上可以让它的用户开心或更有效率。
推论二：软件以两种方式让用户开心或更有效率。首先，它能帮助用户解决一个特定问题—写一篇文章，支付一笔订单，或是给汽车导航。或者，它将用户带入一种愉悦的状态—欣赏音乐、玩游戏，或是和孙子孙女视频聊天。这就是可能存在的两种情形了，尽管有时候两种其实是掺杂在一起的。
推论三：上面的情形里用户并不愿去思考你的程序本身，完全不会。在第一种情形里，他们思考的是自己面对的问题：正在撰写的文档该选怎样的词汇，还有没有足够的钱来支付账单，哪个人的钱要是还不上结果会很惨。而后面的情形，用户只想尽快地进入状态，待在里面越久越好。任何耽误了他们解决问题，或是让他们在享受状态时分心的事情，都不会受欢迎，比在工作时被人打扰更甚。
让我们来总结一下三条推论：用户不关心你的程序，也不关心你本人。现在不会，以后也不会。你亲妈可能会，因为这程序是你写的而她很爱你，但也可能并不会。用户只关注他自己的效率或是感受。每个应用的每个用户都想要一台 Donald Norman 所说的 “看不见的电脑”，就像同名书籍中描述的一样。
你可以看到，在前面的例子中，Google 就在尽可能地隐藏自己，不像 UPS 那样。在心里记着 Platt 第一定律，还有它的三条推论，让我们一起看看另一个案例吧。
示例：要保存吗？
这是你每天都会遇到的状况。这简直可以说成了肌肉记忆，你都不会去想它。但是今天，让我们一起来思考一下。
在微软的 Word 软件里打开一个文档。敲上一些字或者修改一下，然后点关闭按钮。Word 是怎么做的呢？它弹出一个对话框问道，“你想要保存修改吗？”（见图6）一位时尚的视觉设计师可以给“保存修改”对话框换上漂亮的字体，微妙的渐变色，当然还有精致的圆角。但是他没有也不能指出这个问题：这个程序应该像现在这样在用户退出时发出提问，还是应该像微软的 OneNote 一样在修改发生时就自动保存？哪一种方案会让用户更有效率、更开心？问题回到我们交互设计师这儿了，来做一个决定吧。应该如何选择？
让我们从一道算术题开始。Word在每次关闭的时候要求你做一个选择，然后点一次鼠标。如果用户做了100次修改，那他就要做100次选择，点100次鼠标。如果我们采用了自动保存方案，需要在界面找一个其他地方加入某种版本回滚的功能—比如说在编辑菜单里加上一项“放弃当前文件本次所有修改”，可能会需要5次点击来完成。如果99%的情况下用户想要保存修改，自动保存就可以把100次点击砍掉95次，大大减轻了用户的负担。如果只有50%的情况用户想要保存修改，那么自动保存实际上会增加用户的负担—100次点击骤增到了250次。你的程序又该如何选择呢？
图6 微软的Word提示用户保存改动。为什么它不像微软OneNote一样自动保存呢
和平时一样，这要分情况。在 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展示了它的截图。
图7 JoyOfUX.com 网站截图
在这个网站上你可以看到本书提及的一些资源，比如用户画像的模板。我还会增加一些案例，与本书结尾的两篇类似。所以过上一两个月就来看看吧。另外如果你也有一个案例想要贡献出来，我将非常高兴。
本书相关资源也可登录机工新阅读网站（www.cmpreading.com）下载。
让我们开始吧！
Arlo Guthrie 在一首歌中唱到：一个人做，人们认为他疯了。三个人做，人们认为这是一个组织。如果50个人一起做，人们就知道这是一场运动了。
我希望对不好体验的反抗也能达到这样的目标。那么让我们开始吧。
计算机\Web设计
“多年以来，我四处奔走，向每位愿意聆听的人传播‘人人（而不只是专业的体验设计师）都该关注用户体验’的理念。在向开发者解释‘用户体验应该关注什么’这件事上，David 通过完整而紧凑、容易被吸收并能马上付诸实践的形式，做出了伟大的工作。开发者们，请来带走这本书！”
—— Steve Krug，《点石成金:访客至上的Web和移动可用性设计秘笈》作者
一种软件产品能够脱颖而出，用户体验往往是关键。本书通过大量案例，帮助你领会如何提升用户体验，可以作为你学习 UX 设计的第一本书。作者重视细节，耐心讲解实现方法，内容具有可操作性。
—— 阮一峰，《软件随想录》、《黑客与画家》的译者，《ES6 标准入门》的作者
经常有刚入行的设计师问我应该看哪些书来入门，我一直很难给出一个完整的书目，因为 UX 这个课题非常大，所跨专业也非常广，但《The Joy of UX》这本书让我眼前一亮。作者的写作思路和受众都是偏向软件开发者的，所以全书非常贴近真实产品和实际工作，通过数量众多和极其细致的案例分析之后，相信能帮助读者们对 UX 行业的各种概念有深入的理解。
—— JJ Ying，百度MUX上海设计团队负责人， 著名设计类播客 Anyway.FM 主播
高质量的用户体验并不难达成，但它确实需要开发者用新的方式来思考。本书将通过具体的案例来告诉你该怎么做，会帮助你在面临技术困难、工期紧迫、预算紧张等挑战时，优化产品的可用性和参与感。
通过阅读本书，你将学到：
•识别和避开那些导致糟糕用户体验的陷阱
•了解设计与单纯装饰之间的关键区别
•穿上用户的鞋子 —— 理解用户想要什么（以及何时、何地、为什么）
•以易于优化为目标，快速制作草图和原型
•在真实用户或合适的代表人身上测试你的原型
•集成远程数据监测方案，捕捉最具代表性的数据
•使用分析方法，精确解读你收集到的数据
•解决移动环境下特有的体验问题
•在用户体验不打折扣的前提下，给你的应用加强安全性
•为了消除用户的负担，打磨你的用户体验
写这篇译者序的原因，其实就想和读者说说话，或者自言自语几句。在B站看视频的时候，偶尔会想：要是一本书也有弹幕就好了。可以看到读者的吐槽和称赞，了解读者感兴趣的内容。后来在微信读书的app里面，看到了一种实现的可能性，就是让读者选取某一句话来高亮评论，让看书这件事也有了一种微妙的参与感。
阮一峰说过，比较一下花费的时间精力和获得的报酬，翻译实在是一件不划算的差事。然而当他得知有机会接手偶像的新书时，还是毫不犹豫地答应并专门写了一篇博客来表达激动之情。而去年我和同事边蕤在北京参加完一项行业大会准备离场时，偶然在展台上看到了一个熟悉的封面，正是她参与翻译的第一本书。这可能就是译者的喜悦吧。
一天在工作微信群里看到《The Joy of UX》在寻找译者，我就关注了一下，在看到副标题 “User Experience and Interactive Design for Developers”之后立即决定：我要翻译它！在过往的工作经历中，我一直和程序员们打成一片，他们也说我是一个“developer friendly designer”。
回到10年前的大学时光，我泡在图书馆里，一边摆弄着 Photoshop、Flash 做海报、小动画，一边学会了自己用HTML、CSS和那时流行的 jQuery 做个人网站。第一份实习工作就是 Flash 游戏程序员，然而在短短3个月之后就离职放弃了—现实中的开发工作远不是跟着教程做几个 demo 就能搞定的，而我也对程序员的工作有了更多的敬意。
今年，也是初代 iPhone 发布的第10个年头，有人说正是这款产品的流行，让整个行业甚至整个社会重新认识了用户体验设计的重要性。这款产品的设计哲学，我想引用它背后的两名产品设计师的话来传达：一是史蒂夫·乔布斯说的“Design is not just what it looks like and feels like. Design is how it works。”；二是乔纳森·艾维说的“It抯 very easy to be different, but very difficult to be better”。
一件事物、一个名词的流行往往是把双刃剑，我遗憾地发现，直到今天，当一个人提到“UI设计”“用户体验”的时候，你往往并不知道他指的是什么。可能是外观风格，可能是信息的组织与表达方式，可能是从接触到离开整体环环相扣的使用感受，也可能根本不是设计相关的问题。而这本书，正是让你自己动手参与进来，理解谁是你的用户，如何展开产品设计工作，怎么衡量这项设计对用户有没有带来实际有效的价值，以及最重要的—为什么要这样设计。
首先，它是写给开发者看的。不要再担心自己审美不够好、不会手绘、不懂配色，所以做不好设计。作者也不会，但这并不会阻碍他做出杰出、有价值的产品设计。跟着作者行动起来吧！一起认识几名用户，了解他们生活的辛酸与快乐，然后利用书中提供的一套框架，勇敢地做出尝试，测试它的表现，做出一点点修改，并最终让这些亲爱的用户生活得更美好。别忘了，你懂编程，这是一项了不起的技能。我常常羡慕那些独立开发者，在掌握了用户体验设计的基础之后，可以亲手来实现、打磨自己的产品。而你也可以做到。
其次，我觉得它也很适合国内的用户体验设计师群体，特别是新人。很多 “设计师” 都纠结于周围同事不懂得欣赏，不认可自己的作品，自己工作的价值得不到有效体现，并对此感到迷茫。那么翻翻这本书吧，书中的“用户画像”“可用性测试”“数据监测”等名词你一定听过，也可能自己就常常跟别人讲起，可是你了解如何实践，以及为什么做这些吗？我希望通过阅读这本书，你可以跟着书中的案例，重新审视一下自己的日常工作离用户有多远，有没有为他们带来价值，看到自己努力的方向。
我们可以做一枚螺丝钉，也可以成为一个创造者。走出办公室去认识你的用户，从他们身上学习，为他们的真实生活而设计。在他们感受到愉悦的同时，你也会明白用户体验设计的乐趣就在这里。
最后，感谢那些在过往工作中和翻译本书过程提供帮助的朋友们：
感谢 Sebastian 和邹洋，带我入行，让我懂得了什么是交互设计，什么是 sign & feedback。游戏设计远比其他数字产品的设计精妙和复杂，充满乐趣和挑战。
感谢张勋，给予我极大的信任和支持来负责全平台产品的交互设计工作，正是这种难得的机会帮助我成长为一名合格的交互设计师。而他也是我的榜样，让我看到一名优秀的产品设计师应该有怎样的知识视野、管理能力、技能和担当。
感谢目前供职的 ThoughtWorks。它不对员工设限，鼓励知识的融会和分享。这里的用户体验设计团队有机会尝试本书中提及的各项实践，扩宽自己的工作之路。特别感谢小爱帮忙促成本书的翻译。
感谢边蕤，作为一名“过来人”，给我传递了第一手经验，打消疑虑，让我觉得自己也可以挑战翻译工作。
感谢华章的关敏老师和张锡鹏老师，帮忙协调、审稿、编辑，教我这个对流程完全不懂的新人顺利完成翻译工作，还给了我很大的鼓励和宽容。我能从他们身上感受到对图书、生活、知识传播工作的热爱。
最后要感谢家人的支持。特别是我媳妇葱葱，不仅时常督促我这个“拖延”患者保持更新，（尽量）按时交稿，作为中文工作者，她还在最后完稿时认真地帮助校对、润色，消灭了不少不通顺的句子（bug）。
最后感谢你读到这里，这是一本会给你带来启发的书，如果你有疑问或是根据本书做出了令你骄傲的实践，欢迎与我（http://weibo.com/jimmy143）分享。
杨少波
2017年8月于西安
赞誉
译者序
序
前言：用户体验支配一切
第1章 用户画像1
1.1 给用户一张面孔1
1.2 创建最简单的用户画像2
1.3 添加细节5
1.4 使用用户画像10
1.5 使用用户画像获得成功12
第2章 用户想要什么（何时、何地、为什么）14
2.1 我们还没开始编程14
2.2 但用户也不知道他们想要什么15
2.3 找到参与测试的用户16
2.4 采访用户18
2.5 观察用户19
2.6 向极客们解释22
2.7 讲故事23
第3章 绘制草图和原型图27
3.1 制作原型：错误的开始方式27
3.2 从一张好的草图开始28
3.3 原型图制作工具示例：Balsamiq31
3.4 用故事板来说明交互40
3.5 用实际操作来演示43
第4章 让真实用户测试46
4.1 持续地测试，贯彻始终地测试46
4.2 为什么没有测试47
4.3 早早地开始测试50
4.4 从用户体验测试中我们能学到什么51
4.5 找到测试者52
4.6 补偿测试用户54
4.7 测试区的设计和布置54
4.8 使用一名主持人55
4.9 任务的设计和描述56
4.10 观察与盘问57
4.11 用户测试示例58
4.12 对于可用性测试最后想说的66
第5章 远程数据监测与分析67
5.1 猜谜游戏的时代67
5.2 远程数据监测作为解决方案69
5.3 远程数据监测的演化71
5.4 授权和隐私74
5.5 选择一个远程数据监测服务提供商76
5.6 应该追踪什么77
5.7 远程监测示例78
5.8 对于今天的原型远程数据监测的建议82
5.9 错误地使用远程监测83
第6章 安全与隐私85
6.1 一切都是权衡的结果85
6.2 用户首先是人86
6.3 什么是用户真正在乎的87
6.4 麻烦预算88
6.5 案例：Amazon.com93
6.6 给我们的应用建立安全性99
6.7 关于安全性最后想说的108
第7章 让它能胜任工作109
7.1 一切的关键109
7.2 从好的默认设定开始110
7.3 记住一切应该记住的114
7.4 使用用户的语言讲话115
7.5 别让用户去做本该你做的工作117
7.6 别让边缘情况支配主流场景119
7.7 别让用户去思考121
7.8 别让用户来确认123
7.9 支持撤销124
7.10 恰到好处的可定制度130
7.11 引导用户132
第8章 案例分析：通勤铁路手机应用135
8.1 可怜可怜这些上班族吧135
8.2 当前进展136
8.3 第一步：谁140
8.4 第二步：什么（何时、何地、为什么）143
8.5 第三步：怎么做148
8.6 第四步：测试一下150
8.7 第五步：远程监测方案155
8.8 第六步：安全与隐私规划156
8.9 第七步：让它能胜任工作157
第9章 案例分析：患者门户网站160
9.1 不错的初次尝试160
9.2 现状如何161
9.3 第一步：谁170
9.4 第二步：什么（何时、何地、为什么）173
9.5 第三步：怎么做175
9.6 第四步：测试一下178
9.7 第五步：远程监测方案184
9.8 第六步：安全和隐私规划185
9.9 第七步：让它能胜任工作187
