本书由日本的一位樽本徹也著，陈啸译。特整理了简要的读书笔记，希望大家1小时左右即可了解本书的核心内容。
前三章笔记见之前的博客文章：https://blog.csdn.net/zimingzim/article/details/81192386
第4章 产品可用性评价方法
4.1什么是评价
4.1.1总结性评价和形成性评价
期末测验和小测验
形成性评价更重要：产品可用性的评价也分为总结性评价和形成性评价；比较典型的总结性评价方法是性能测试法；比较典型的形成性评价方法是发声思考法。总结性评价一般是在设计前和设计后使用，形成性评价会在产品设计的过程中反复使用。
4.1.2分析法和实验法：分析法也被称为专家评审；实验法收集货真价实的用户使用数据，比较典型的是用户测试法，但问卷调查等方法也属于此类。
分析法的优点：设计初期也可评价；时间和费用较小；评价范围广；
分析法的缺点：结果比较主观。
4.2产品可用性检验：专家根据自身的知识见解，参照用户界面设计的指导手册进行界面评价的分析方法的总称。
4.2.1启发式评估法：分析很多产品可用性问题后，提炼出隐藏在背后的产品可用性原则。
4.2.2启发式评估十原则
1、系统状态的可视性（系统必须在一定的时间内做出适当的反馈，必须把现在正在执行的内容通知给用户）；
2、系统和现实的协调（系统不应该使用指向系统的语言，必须使用用户很熟悉的词汇、句子来和用户对话）；
3、用户操控与自由程度（用户经常会因为误解了功能的含义而做出错误的操作，为了让他们从这种状态中尽快解脱，必须有非常明确的“紧急出口”）；
4、一贯性和标准化（不应该让用户出现不同的词语、状况、行为是否意味着相同的意思这样的疑问，一般应该遵循平台的惯例）；
5、防止错误（能一开始就防止错误发生的这种防患于未然的设计要比适当的错误消息更重要，更因该做到的是预防出错）；
6、识别好的回忆（要把对象、动作、选项等可视化，使用户无需回忆，一看就懂）；
7、灵活性和效率（用户频繁使用的操作要能够单独调整）；
8、简洁美观的设计（在用户对话中，应该尽量不要包含不相关及几乎用不到的信息，应该做到简洁美观）；
9、帮助用户认知、判断及修复错误（使用通俗的语句表示错误信息，而不是显示错误码，明确指出问题，并提出建设性的解决方案）；
10、帮助文档及用户手册（能够在没有用户手册的帮助下也可以使用，但还是有必要提供帮助文档和用户手册）；
专栏：用户界面设计的铁则
施耐德曼博士的八项黄金原则；IBM的设计原则；ISO 9241 Part-10：对话原则；
4.2.3启发式评估法的实施步骤
STEP1：招募评价人员
STEP2：制定评价计划（启发式评估法可以评价界面中的大部分内容）
STEP3：实施评价（评价人员单独进行评价，禁止互相评论；尼尔森博士推荐两次评价，第一次检查界面的流程是否正常，第二次详细检查各界面是否存在问题。）
STEP4：召开评价人员会议（一般需要半天时间）
STEP5：总结评价结果（产品可用性问题列表，配上界面截图、界面流程图等形成简单的报告；集体讨论，当场商议问题的解决对策，这才是最有效率的做法）
4.2.4启发式评估法的局限性
查出的问题过多（理论上是对用户界面进行彻底的批判，势必会发现很多问题）
实施成本（根据实施方法的不同，有时会发现成本意外增长了不少）
专栏：认知过程走查法
基于人类的认知模式进行检验的方法。基于用户认知模型之一的探索学习理论寻找问题。四个步骤（设定目标；探索；选择；评价）。认知过程走查法的分析步骤（问题1、用户是否知道自己要做什么？问题2、用户在探索用户界面的过程中是否注意到操作方法？问题3、用户是否把自己的目的和正确的操作方法关联到一起？问题4、用户能否从系统的反馈中判断出任务是否在顺利进行？）
4.3什么是用户测试：典型的实验型方法。基于真实用户数据进行的评价，有足够的说服力。
4.3.1用户测试体验记
4.3.2用户测试的概要：请用户使用产品来完成任务；观察并记录用户使用产品的整个过程。
4.4具有代表性的测试方法
4.4.1发声思考法：一大特点就是让用户一边说出心里想的内容一边操作。与回顾法属于形成性评价。
观察的重点：用户是否独立完成了任务；用户在达到目的的过程中，是否做了无效操作或遇到了不知所措的情况；用户是否有不满情绪。
4.4.2回顾法：让用户在完成操作后回答问题的方法。
回顾法的缺点：很难回顾复杂的状况；用户经常在事后为自己的行为找借口；回顾法非常耗时。
所以主要采用发生思考法，特定背景下，使用回顾法补全想要的信息。
4.4.3性能测试
测试项目：主要对可用性三要素（有效性--任务完成率、效率--任务完成时间、满意度--主观评价）相关数据进行定量测试。
测试方法：经常以集体测试的形式进行。
性能测试的缺点：设计团队可能认为性能测试起不到什么作用。
性能测试适用的场景：属于总结性评价的范畴。无论在时间和金钱上都是奢侈的测试。只要还未明确定量数据的必要性，就不应该实施性能测试。
专栏：产品可用性问卷调查法
欧美国家的调查表（QUIS、SUMI、WAMMI）、日本的调查表（WUS）、使用调查表时的注意事项（纸质调查或网页调查；适合总结性评价；不应该改变问卷里的任何内容）
4.5用户测试的基础理论
4.5.1产品可用性的理论基础：用户测试是以反证为目的的测试。
什么是反证：假设该用户界面具备可用性，用户实际操作来验证一下，如果违背了有效性、效率和满意度的问题，那就是该假设的反证。
测试前的准备：想做用户测试，至少要先做出值得反证的页面。
4.5.2用户测试的参与人数：参加测试的用户人数为5-6人，而不是几十人。
尼尔森公式的漏洞：即使发现了85%的问题，仍然包含两种可能性，即发现了严重的问题，或没有发现严重的问题。
5人参与测试的真正用意：一定要进行测试，即使人少也要进行。
专栏：比较调查是失败的根源
比较缺点；数据的信赖区间；无须知彼。
4.6用户测试的实践基础
4.6.1招募：像招募广告一样把招募条件简洁地总结出来。
4.6.2设计测试需要事先进行试点测试。
4.6.3实际操作：前台接待；签署录像同意书和保密协议；访谈；观察任务执行过程；奉上报酬，送客。
4.6.4分析与报告：重新观看测试时的录像并做记录；记录完成后，仔细重读每个参与者的测试记录，挖掘可用性问题；上述信息整理后做成报告；尽量搭配界面示意图和录像截图等，让报告一看就懂。
4.6.5时间与费用
4.7推荐DIY用户测试：Do it yourself
4.7.1轻量化趋势：项目轻量化
4.7.2Do-It-Yourself：如果实在没有预算，那就Do it yourself，做测试并不是最终的目的，真正的目的是开发产品，用户测试不过是一种手段。因此，无论看上去多么简单的测试，只要能提高产品品质就够了。
4.7.3二八定律：把注意力放在决定了80%的价值的这20%的元素上。理论上看Do it yourself可以发现与正规测试相同数量的问题。总体来看，DIY用户测试可能比正规测试得到更大的成果。
4.7.4DIY的基本原理
充分利用人脉：如果充分利用人脉，确实可以结交到超出想象的数字的人。
有效利用日常用品：稍微发挥下想象力，就可以发现原来身边可以用来做测试器材的物品有那么多。
原始的分析方法：亲和图法（ 核心是头脑风暴，是根据结果去找原因）。用户测试中可以使用。
重视对话：DIY用户测试要求相关人员必须参加，一起讨论问题的解决方案。
4.7.5用户测试的失败案例：不少开发人员和设计师都会等产品开发结束后再做测试，其实就是希望把测试往后延，有些致命问题应该尽早发现；很多人认为，如果参与者是新手，可能会发现更多问题，这个想法也是完全错误的；千万不要把用户测试当成市场调查时做的小组访谈，用户测试需要单独进行；不可以向用户提出“您觉得哪里不好”“您觉得如何改进会比较好”这样的问题，用户测试应该做到不盲从用户的意见。
专栏：低成本用户测试的发展
尼尔森主张如下：定期、反复地进行小规模的测试；要求相关人员参与观察用户测试；问题的解决方案永远没有最好，只有更好。
布鲁格原则：无论什么样的测试，总比不做好；尽早测试；反复测试；
第5章 用户测试实践篇
5.1招募
5.1.1招募前的准备：用户测试第一步就是招募。招募条件：参与者必须具备相应的资格；还需要有一定的经验。
5.1.2通过人脉招募：DIY用户测试，通过对话的方式即可。六度空间理论。
5.1.3抓住一切机会：发挥想象力，注意观察周围，就能发现很多地方可以找到符合条件的参与者。如走廊、展会、讲座、培训班、公司顾问等。
5.1.4招募的窍门
性别年龄不限：DIY测试应尽量避免询问这些私人信息，可以通过介绍人保证参与者的来历。
按参与者的喜好定时间：正规用户测试需要参与者特定时间达到，DIY正好相反。
逐渐展开：不要轻易拒绝多招募到的人，慢慢开展用户测试。
专栏：报酬的行情
应该在了解这些专业人士的报酬行情的基础上决定相应的金额。
5.2设计DIY测试
闹剧.用户测试剧场
测试设计由四个步骤组成：设计任务；准备实验检查工具；制作访谈指南；进行试点测试。
5.2.1设计任务：任务很大程度影响测试的结果，可以把任务理解为用户测试的关键。四大原则：把精力锁定在主要任务上（可以从研发目的的角度出发）；从用户角度出发（避免不切实际）；明确起点和目标（如果没有明确定义目标，就不能判断用户是否完成了任务）；剧本化（追加一些假设的情况，把任务润色成故事，用户可以通过自己以往的经历，带着生活实感，更主动地使用产品）。
5.2.2准备实际检查工具：用户在来测试会场之前是不作任何准备的。如果不事先准备好用户执行任务时需要的信息和环境，测试就不能顺利进行。
准备：可能用到的信用卡、电话的联络人、拍摄物品、商品照片和手册等，按照真实场景模拟。
信息提示卡：有助于用户更主动地使用这些信息。
初始化操作指南：每个参与者完成后都要进行初始化。
5.2.3制作访谈指南：访谈指南就是用户测试的剧本。
测试大纲：用户测试不仅由任务构成，还包括签订保密协议、支付酬劳、事前访谈、事后访谈等，
访谈指南示例：测试概要（评测对象；招募条件；参与者人数；任务；测试时间；酬劳）
网站的相关访谈：1、序曲；2、事前访谈；3、事前说明；4、观察任务执行；5、时候访谈；6、尾声；7、初始化环境。
5.2.4进行试点测试：不管设计多严密，实施都会有偏差，因此，需要事先进行试点测试，参与者一般是公司同事。试点测试绝不可以省略。
专栏：其他与任务有关的内容
任务设计是一项专业的技能，更需要丰富的经验。
5.3简易实验室
5.3.1测试地点：原则上不会使用产品可用性实验室，公司的会议室就可以用来使用。
5.3.2测试设备：需要观察用户的发言和行为。
计算机：推荐测试专用笔记本；准备录音的麦克风。
智能手机/平板计算机：投影仪观察用户的细微动作。
家电、车载导航仪、办公自动化设备
纸质原型：如果需要的话，可以摄像。
专栏：DIY投影仪
5.3.3录像方法：推荐在测试时录像。
计算机：一般会使用视频捕捉软件进行录像。
其他
专栏：PinP
DIY用户测试中最好不要对用户面部表情进行录像，因此没有必要采取PinP技术。
5.4访谈：一旦进入测试核心部分，即任务执行观察阶段，采访人员应尽量隐藏自己。
5.4.1不提问、不回答：基本原则是正确地传达指示后，让用户自由发挥。
5.4.2实况转播：发生思考法；实际操作中，可能需要引导用户发言。
5.4.3事后询问：回顾法。
5.5观察：百闻不如一见。
5.5.1增加“目击者”：用户测试目击者越多，越有利于迅速做出重大决定；尽量让每个观察员参加三场以上测试的时间。
5.5.2观察的礼仪：必须遵守一定的观察礼仪（打招呼；不注视；不发声；不介入）
5.5.3观察的技术：用户测试中只需要观察在什么页面发生了什么，以及当时用户说了什么就够了，接着把这些事实印在脑海里。
专栏：用户真的喜欢优惠吗（用户测试中不应该对用户言听计从）
专栏：发声思考的理想与现实（说起来容易作起来难）
5.6分析
5.6.1张贴：用户测试中的观察，能够得到的数据主要是定性的数据。
注意：1、所记述的内容不应该是所谓的“注意点”，而应该是观察到的“事实”；2、请从“用户的角度”进行记述。
5.6.2映射：把界面和观察数据相关联
5.6.3影响度分析：从问题性质和发生频率两个方面来分析影响度。
专栏：任务完成状况一览表
5.7再设计
5.7.1交谈比文档更值得重视：最具有效果并富有效率的传递信息的方法，就是面对面的交谈。把时间花在和开发人员、设计人员一起研究问题的解决方案上。
5.7.2解决问题：若能够解决产品里导致用户体验不好的最为深刻的根本问题，就能够让产品的品质得到质的飞跃。优秀的创意往往简单到让人意外。切忌不要想着尽善尽美。
5.7.3反复设计：随着哟过户测试的反复进行，开发团队的能力往往也会逐步提升。以用户为中心的设计的最大原则即是反复进行试制和测试。
专栏：小变更带来大成果
小故事：一目了然的自动识别并给出候补菜单、地铁刷票系统倾斜13度、快递收发人的两个单词“您”和“他”
专栏：推荐使用头脑风暴法
头脑风暴法的4+3原则：严禁批判；自由奔放；量比质重要；欢迎搭便车；可视化；严禁跑题；每人一次发言；
以用户为中心的会议：与会者是互助关系，可以与背景调查法、用户测试等经典方法相匹敌。
5.8隐私与伦理
5.8.1个人信息保护：尽量避免获取个人信息；获取到的信息要尽量做到匿名化；
5.8.2伦理上的责任：不要让参与者感到不愉快
事前的说明和同意：知情同意书
精神上、身体上的安全：精神上的负担往往超乎想象
规避具有利害关系的人：用户测试的结果，只因该用于改善产品。
专栏：不要轻易测试
万万不可武断的测试。
第6章 超越UCD，走向敏捷UX开发
6.1推荐非瀑布型UCD：通过反复地创建模型和不停地测试，慢慢提高产品的完成程度。
6.1.1流程的差异
6.1.2沟通方式的差异：UCD中仍然比较重视文档
6.1.3“慢慢地”的差异：UCD是迭代式的开发模式
6.1.4敏捷开发vsUCD：如今，敏捷开发已慢慢地进化成了渐进和迭代两者兼备的开发模式
6.2敏捷开发的潮流
6.2.1敏捷UX简史：90年代后半段完成自身理论建设；21世纪初出现了结合敏捷开发和UCD两者进行的开发。
贝克对库珀：敏捷开发的思想碰撞
6.2.2敏捷UX的基本原则
由内而外：不开发多余的功能，从用户最有价值的核心功能开始开发，慢慢地扩展到可选功能上。
平行推动：成功的关键就是先做UX设计，这就是平行轨道法。
轻装上阵：需要在万分小心、不损害到各个方法的前提下，消减没用的部分，轻装上阵。
6.2.3敏捷UX的理论基础：敏捷开发、以使用为中心的设计和以用户为中心的设计这三种模式慢慢地融合，最终形成今天的敏捷UX开发模式。
6.3使用敏捷UX开发
6.3.1产品概念：为了谁，做什么？在创意达到用户认可的程度之前，需要反复进行调查、构思和检验。
6.3.2计划：组织团队；确立计划；通过用户故事定义需求；预估作业模型；用户故事实现顺序；用户故事列表管理。
6.3.3开发：以首次发布产品为目标的开发过程。
6.3.4发布：迭代期的反复，产品逐渐完成，就可以发布了。
专栏：RITE法
快速迭代式测试和评估法
快速迭代：测试与设计变更的快速迭代
与一直以来的方法的差异：轻量级测试方法的先驱，有5个人参与的用户测试就足够了。采用RITE法，哪怕只观察了一位测试者，但只要问题已经明确化，就可以马上进入研究改善的流程，接下来第二位测试者，就可以使用改善后的界面来测试了，通过这样的反复过程，十来位测试者测试后，相信产品可用性问题已经被消灭干净了。
RITE法的前提条件：当然就是指通过观察1个人来做判断点（非常困难且风险极高，需要具备丰富的经验）；另一个就是开发能力；RITE法是一种要求非常高的方法。
RITE法的理念：若不能解决问题，就没有任何意义；我们的目的并不是实施测试，而是开发产品。RITE法正是进行了逆向思维，与发现问题的精确度相比，问题的解决更为优先。
附录 敏捷UX的故事
敏捷开发宣言：个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。
产品经理首先思考产品的概念--为谁，做什么（方法1 ：游击调查法）。
一旦限定任务，就开始研究解决方案，构思一个独一无二的创意，需要头脑风暴法（方法2：游戏风暴）。
在立项之前对创意进行验证，反复进行调查、构思、验证这一步骤，直到得到用户的高度认同（方法3：概念测试）。
一旦确定了产品概念，就要正式组建团队（Scrum团队，由产品负责人、开发团队和团队主管组成）。
一旦开发团队完成，就应该着手制定项目的开发计划。首先，需要建立虚拟用户角色（方法4：实用的虚拟用户角色），把需求分割成许多小的特性记录到卡片里。然后我们预估各种各样的用户故事的作业规模（方法5：用户故事）。
接下来，决定到底安什么顺序实现这些故事（方法6：计划扑克）。为了把握产品的整体印象，我们需要使用用户故事的二位图表进行管理（方法7：故事地图）。
终于要开始介绍实现用户故事的开发流程了（方法8：Scrum板）。
UI设计也可以在迭代开发中同步进行，此时可以采用草图法（方法9：草图法）。
下面，我们要为那些操作起来非常复杂但却非常重要的界面制作原型（方法10：纸质原型）。
一旦原型制作完成，应该马上实施用户测试（方法11：用户测试）。
每个迭代期结束后，都应该向相关人员进行产品的实际演示，并听取他们的反馈（Demo or Die！演示一伙死亡），通过反复进行3-6个月左右的产品发布，产品得以不断完善，业务也逐步成长壮大。
后记
UCD和质量管理一样，属于系统性工作。
用户可用性成熟度模型：1、原始期（用户界面的设计完全依赖于界面设计师和软件工程师的个人能力）；2、黎明期（将用户测试作为产品公开前的最终检测加以实施）；3、摇篮期-前期/后期（用户测试作为一种有效的设计手段固定存在项目中）；4、活跃期（通过开发剧本和虚拟角色来探索用户需求）；5扩充期（会跟踪调查产品发布后的使用情况）；6、成熟期（建立产品可用性知识数据库）。
请至少做到摇篮期水平