用户体验与可用性测试

　　好设计，原来是这样测出来的！
　　产品被吐槽，肯定是某些地方没考虑周到！
　　为什么不能指望用户的意见？
　　所谓的头脑风暴，真的有用吗？
　　应该如何限定你的目标用户群？
　　怎样的用户调查才是真正有效的？

　　《用户体验与可用性测试》是用户体验与可用性测试的入门级读物。作者基于多年的经验，围绕用户调查、原型制作、产品可用性评价、用户测试，结合具体案例，提供了极其实用的方法和实践技巧，同时也介绍了敏捷用户体验开发的相关内容。

　　樽本徹也，产品可用性工程师、UCD咨询师、敏捷UX培训师。在用户调查及产品可用性评价方面有丰富的经验。

　　陈啸，上海同济大学计算机科学与技术专业毕业。后入职日本某株式会社上海子公司，从事车载导航器开发工作，其间赴日本总公司进修。回到上海后，作为项目经理参与Android手机和iPhone手机应用、车载导航器等众多项目的管理，对产品可用性工程学兴趣浓厚。

第1章　以用户为中心的设计概论
1.1　UX和UCD
1.1.1　体验的价值
1.1.2　UX的构成
1.1.3　UX的实现方法
1.1.4　UCD的要点
流程的质量
螺旋上升的设计流程
用户的参与
专栏 UX的国际标准
1.2　产品可用性≠产品易用性
1.2.1　产品可用性可有可无吗
1.2.2　根本没法用的产品
乱七八糟的搜索引擎
繁琐的订单页面
没法后退的网站
1.2.3　产品可用性的定义
有效性
效率
满意度
1.3　产品失败的原因
1.3.1　橡胶用户
1.3.2　产品使用背景
例1：转接非常麻烦的公司分机
例2：销声匿迹的BP机
例3：不会用到的重置按钮
1.3.3　用户体验的点与线
1.4　UCD的最新四原则
1.4.1　不要盲从用户意见
1.4.2　只为一人设计
1.4.3　边做边想
1.4.4　早期试错
第2章　用户调查法
2.1　老套的访谈方法
2.1.1　用户意见的局限性
为什么不能指望用户意见
摈弃意见，分析行为
2.1.2　小组访谈的局限性
小组访谈以提意见为主
平均每人16分钟
加以润色的故事
2.1.3　访谈的局限性
按计划进行的访谈
归纳过的信息
2.2　师徒式访谈
2.2.1　背景调查法
背景式访谈
2.2.2　徒弟的思想准备
基本技能
访谈案例
访谈的注意事项
不能被察觉出你是专家
不要去验证你的假设
不要在无效的问题上纠缠
2.2.3　选择师父的方法
师父的条件
要找多少位师父
调查公司的样本库
人脉
2.3　访谈实践
2.3.1　如何设计访谈
2.3.2　访谈的地点、设备和人员
地点
设备
人员
2.3.3　进行访谈
构建信赖关系
把握用户个人信息
把握使用情况
访谈结束
验证假设型访谈
专栏 前辈和后辈
2.4　情景剧本
2.4.1　文档化的必要性
2.4.2　什么是情景剧本
使用情景剧本的好处
2.5　分析情景剧本
2.5.1　情景剧本的写法
创作单个故事
推敲情景剧本
2.5.2　评测情景剧本
再次访谈
评测访谈的不足之处
2.5.3　情景剧本的使用方法
货真价实的任务
真正的用户需求
2.5.4　探索用户需求
步骤一：分解
步骤二：分析
步骤三：思考
分析示例：与在线词典服务的使用相关的情景剧本
2.5.5　分析情景剧本的好处
专栏 角色
第3章　原型
3.1　什么是原型
3.1.1　原型的作用
实验模型
试用品
3.1.2　高保真和低保真
3.1.3　T原型
3.1.4　奥兹国的魔法师
3.2　原型的制作方法
3.2.1　制作工具
纸质界面
无形的原型
3.2.2　制作的重点
不要忘记做假的页面
需要具有高保真度的元素
保真度较低也无妨的元素
3.2.3　由谁来制作
是否一定要做出完美的原型
制作原型所需的技能
专栏 用PPT来制作原型
3.3　卡片分类法
3.3.1　层次结构的设计
3.3.2　封闭式卡片分类法
封闭式卡片分类法的步骤
也可以在线调查
3.3.3　开放式卡片分类法
聚类分析
分类合并
3.3.4　Delphi卡片分类法
什么是Delphi法
Delphi卡片分类法的优点
第4章　产品可用性评价方法
4.1　什么是评价
4.1.1　总结性评价和形成性评价
期末测验和小测验
形成性评价更重要
4.1.2　分析法和实验法
分析法的优点
分析法的缺点
4.2　产品可用性检验
4.2.1　启发式评估法
4.2.2　启发式评估十原则
系统状态的可视性
系统和现实的协调
用户操控与自由程度
一贯性和标准化
防止错误
识别好过回忆
灵活性和效率
简洁美观的设计
帮助用户认知、判断及修复错误
帮助文档及用户手册
专栏 用户界面设计的铁则
4.2.3　启发式评估法的实施步骤
STEP 1：招募评价人员
STEP 2：制定评价计划
STEP 3：实施评价
STEP 4：召开评价人员会议
STEP 5：总结评价结果
4.2.4　启发式评估法的局限性
查出的问题过多
实施成本
专栏 认知过程走查法
4.3　什么是用户测试
4.3.1　用户测试体验记
4.3.2　用户测试的概要
4.4　具有代表性的测试方法
4.4.1　发声思考法
观察的重点
4.4.2　回顾法
回顾法的缺点
4.4.3　性能测试
测试项目
测试方法
性能测试的缺点
性能测试适用的场景
专栏 产品可用性问卷调查法
4.5　用户测试的基础理论
4.5.1　产品可用性的理论基础
什么是反证
测试前的准备
4.5.2　用户测试的参与人数
尼尔森公式的漏洞
5人参与测试的真正用意
专栏 比较调查是失败的根源
4.6　用户测试的实践基础
4.6.1　招募
4.6.2　设计测试
4.6.3　实际操作
4.6.4　分析与报告
4.6.5　时间与费用
4.7　推荐DIY用户测试
4.7.1　轻量化趋势
4.7.2　Do-It-Yourself
4.7.3　二八定律
4.7.4　DIY的基本原理
充分利用人脉
有效利用日常用品
原始的分析方法
重视对话
4.7.5　用户测试的失败案例
专栏 低成本用户测试的发展
第5章　用户测试实践篇
5.1　招募
5.1.1　招募前的准备
5.1.2　通过人脉招募
5.1.3　抓住一切机会
5.1.4　招募的窍门
性别年龄不限
按参与者的喜好定时间
逐渐展开
专栏 报酬的行情
5.2　设计DIY测试
闹剧.用户测试剧场
5.2.1　设计任务
5.2.2　准备实际检查工具
准备
信息提示卡
初始化操作指南
5.2.3　制作访谈指南
测试大纲
访谈指南示例
网站的相关访谈
5.2.4　进行试点测试
专栏 其他与任务有关的内容
5.3　简易实验室
5.3.1　测试地点
5.3.2　测试设备
计算机
智能手机/平板计算机
家电、车载导航仪、办公自动化设备
纸质原型
专栏 DIY投影仪
5.3.3　录像方法
计算机
其他
专栏 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　张贴
5.6.2　映射
5.6.3　影响度分析
专栏 任务完成状况一览表
5.7　再设计
5.7.1　交谈比文档更值得重视
5.7.2　解决问题
5.7.3　反复设计
专栏 小变更带来大成果
专栏 推荐使用头脑风暴法
5.8　隐私与伦理
5.8.1　个人信息保护
5.8.2　伦理上的责任
事前的说明和同意
精神上、身体上的安全
规避具有利害关系的人
专栏 不要轻易测试
第6章　超越UCD，走向敏捷UX开发
6.1　推荐非瀑布型UCD
6.1.1　流程的差异
6.1.2　沟通方式的差异
6.1.3　"慢慢地"的差异
6.1.4　敏捷开发 vs UCD
6.2　敏捷开发的潮流
6.2.1　敏捷UX简史
贝克对库珀
6.2.2　敏捷UX的基本原则
由内至外
平行推动
轻装上阵
6.2.3　敏捷UX的理论基础
6.3　使用敏捷UX开发
6.3.1　产品概念
6.3.2　计划
6.3.3　开发
6.3.4　发布
专栏 RITE法
附录　敏捷UX的故事
后记

　　产品可用性工程师这个职业在日本可能没多少人听说过，但在欧美国 家已经有了专门的职位。微软、IBM、SAP 等大公司自不待言，大量软件公司和互联网企业也已设立了相关部门，同时也成立了不少相关咨询公司。在网站可用性领域享有盛名的雅可布? 尼尔森博士，也曾作为 Sun 公司的产品可用性工程师（他被称为“特别工程师”）活跃在业界中。
　　最近几年，产品可用性这个词越来越为大众所知，作为产品可用性工 程师的我，自然也接到了很多业务委托。
　　举一个例子，下面是来自某服装公司网站负责人 A 先生的委托。
　　“最近，我们公司正着手进行网站升级。此次升级的目的之一就是让网站变得更加好用，因此我们专门聘请了设计人员和了解产品可用性的业界人士。现在网站的设计已经基本完成，预计下个月就可以开放使用了。在网站开放之前，我们想请产品可用性工程师用他们的专业知识评测一下我们的网站，进而提供一些能使网站使用起来更加方便的宝贵意见。此外，我们也听说有一种叫作产品可用性测试的调查方法，麻烦您给我们的网站做一下这个测试，我们想收集来自用户的第一手资料，反馈到这次的网站升级里。麻烦您了。”
　　当然，有业务找上门来我肯定是十分欢迎的。但老实讲，对于这种情 况，我能做的实在有限。很抱歉地说，这个项目现在才来咨询恐怕为时已 晚。其实不止开发网站，在计算机软件、手机、数字家电等项目中，类似 A 先生这样的委托也经常发生。
　　无法解决问题难道是因为我们产品可用性工程师无能吗？我不敢苟同。事实上，解决此类问题我是胸有成竹的，这个方法就是——早点来咨询我们。那样，我们也一定可以用产品可用性工程学的专业知识提供更有效的解决方法。
　　然而，在日本，产品可用性工程师实在是太少了，一般的设计团队几乎没有机会接触这方面的技术，因此经常会出现这样的问题，即难得项目负责人关心起了产品可用性问题，却因为不知道操作方法而导致资源浪费。
　　本书主要介绍利用产品可用性工程学进行的设计流程及相关方法。如果你是产品经理，通过阅读本书就能了解，在项目的哪个阶段分配什么样的任务给产品可用性工程师，才会带来最好的效果。如果你是设计人员或程序员，学会了产品可用性的技术，（与把工作托付给那些数量少得可怜的产品可用性工程师相比）就能以“更高的效率、更小的代价”来提高工作质量。
　　如果刚才提到的那位网站负责人在网站升级开始之前就读到这本书，也许结果就大为不同了吧。因此大家一定要在着手进行下一个项目之前读一下本书，那么我相信，下一个项目一定会带给你截然不同的体验。