用户体验与可用性测试_读书笔记

第一章 以用户为中心的设计概论

1.1 UX 和 UCD

1.1.1 体验的价值

1.1.2 UX 的构成

<体验经济> 按照经济价值来计算一杯咖啡的价格

加瑞特倡导的 <用户体验要素> , 多数和 UX 相关的内容必须要从框架层和框架层来了解

1.1.3 UX 的实现方法

UCD: 调查 > 分析 > 设计 > 测评 > 改进 > 反复

1.1.4 UCD 的要点

流程的质量 / 螺旋上升的设计流程 / 用户的参与

1.1.5 专栏: UX 的国际标准

ISO 13407

ISO 9241-210

UX 的定义

1.2 产品可用性不等于产品易用性

1.2.1 产品可用性可有可无吗

usability 是基本需求, 不是魅力需求

1.2.2 根本没法用的产品

乱七八糟的搜索引擎: 搜到的全是广告; 弄错了大小写就搜不到东西

繁琐的订单页面

没法后退的网站

1.2.3 产品可用性的定义

Effectiveness: 做对事情, 达到目的

Efficiency: 最短路径

Satisfaction: 有没有不愉快的体验? (比如注册时需要提供太多隐私信息)

1.3 产品失败的原因

1.3.1 橡胶用户

把用户群假设为 ‘‘关注时尚, 注重自我的成年人’’ , 就和没有定义对象用户一样. 一个产品不能把所有的人都当做用户, 比如 ‘‘敞篷越野面包车’’ .

橡胶用户 (Elastic User) 可以根据设计人员的想象而随心所欲地变化 —— Alan Cooper

1.3.2 产品的使用背景

1.3.3 用户体验的点与线

1.4 UCD 的最新四原则

1.4.1 不要盲从用户的意见

以 ‘‘满足用户要求’’ 为前提的开发搬来就是错的

不能盲目听错诸如 ‘‘你们的产品如果有这样的功能就好了’’ , 这样的用户意见. 用户所说的是对自己的体验做出了分析的结果, 不能保证用户分析的正确性. 我们要关注的是用户体验, 是未经分析的第一手数据 (FACT)

1.4.2 只为一人设计

事先要捉摸清楚, 哪些人, 为了什么目的, 使用我们的产品

大胆的设想 ‘‘不要为所有的用户设计, 而只为一个人设计产品’’ .

1.4.3 边做边想

一边思考, 一边绘制简单的示意图

1.4.4 早期试错

Early / Samll / Often / Smart

第二章 用户调查法

2.1 老套的访谈方法

2.1.1 用户意见的局限性

为了给改善界面, 必须先收集问题相关的数据, 再从数据中分析原因 (界面元素/界面变换/信息等), 最终才推导出解决方案. 我们要做的是摒弃用户的意见, 分析用户的行为 (FACT) , 行为数据是未经分析的新鲜数据, 设计团队要满足用户自己都没有发现的潜在需求.

2.1.2 小组访谈的局限性

Focus Group Interview: 一般会按照年龄, 性别, 经验, 生活方式等等划分小组, 每个小组 6 个人左右

缺点:

小组访谈的得到的大多数都是意见, 而不是 Fact

每个人发言时间有限

参加人员之间发言互相影响, 会对故事加以润色

2.1.3 访谈的局限性

按照计划问题进行

用户回答的都是归纳过的信息, 不会事无巨细的告诉你交通路线, 玩了什么, 等了多长时间等等, 而且用户一般都只说标准情况, 不会提到特殊情况

2.2 师徒式访谈

2.2.1 背景式访谈

采访人员拜入用户门下 >

用户一边演示体验一边说明 >

采访人员遇到不懂的地方时提问 >

采访人员将自己理解的内容复述给用户听(核实)

Contextual Inquiry ——Karen Holtzblatt

2.2.2 徒弟的思想准备

只有清楚了用户行为的背景和细节的前提啊, 才能提出有用的问题. 因此, 问题是随着谈话内容的推进 (了解了用户行为之后) 而自然出现的.

• 访谈步骤: 请教 > 刨根问底 > 核实
• 不能让用户察觉出你是专家
• 不要去验证你的假设 (不要问: 如果有 XX 功能的话你觉得怎么样. 这样收集到的是用户意见, 而不是用户体验)
• 不要再无效的问题上纠缠

2.2.3 选择师父的方法

师傅的技术和经验比较重要

实际操作时, 用户群一般设定为 3~6 组, 每个用户群大概 5~6 人

使用调查公司的样本库招募志愿者或者通过自己的人脉

---

? 案例: 背景式访谈

访谈人员: 您每天要浏览 50 封以上的邮件杂志, 还要把他们分类, 这很耗时吧? ^请教

用户: 还好, 虽说是浏览, 其实也就是一目十行地读. 一般情况下, 光从寄件人和标题就能大概判断出内容了, 之后在快速扫一眼正文的目录就差不多了. 再者, 大多数的邮件杂志都是把吸引眼球的内容放在正文的开头和结尾部分. 先看一下最下面的文字, 如果感兴趣的话, 再返回开头仔细地阅读.

访谈人员: 吸引眼球的内容是指哪些内容呢? ^刨根问底

用户: 比如说像 ''奖金 100 万! ‘’ 这样的悬赏是肯定会看的. 还有, 我订阅的邮件杂志中有一些非常流行的专栏, 一般登再邮件杂志的最后部分

…

采访人员: 申请很多邮件杂志的话, 慢慢的杂志数量会越来越多, 关于这点, 您一般怎么处理呢? ^请教

用户: 登录之后, 最新的五封邮件我都会仔细阅读. 这样的话, 基本就能清楚这些杂志主要讲的是什么内容, 如果对这家咋着的主题没什么兴趣的话就会退订.

采访人员: 退订的操作是什么样的呢? ^刨根问底

用户: 比较简单, 一般的邮件杂志, 最下方都会有退订链接. 单击这个链接, 就会发送取消邮件, 或者跳转到退订的页面上去.

采访人员: 有不是这样的情况吗? ^刨根问底

用户: 有, 还不在少数. 邮件里并没有推定的网址链接, 就只好到它的官方网站上去取消, 如果找不到的话就没有办法了. 还有的情况是想退订, 却发现忘记了用户名和密码. 此时就会用出生年月, 地址, 电话号码之类的逐个尝试, 还是不行的话, 也就没有办法了. 找客服也比较麻烦, 所以不会去找. 这样的邮件杂志, 即便收到了也不会看, 会立刻删除.

采访人员: 原来如此, 看来发送退订的邮件是最简单的, 而且如果利用用户名和密码可以方便地取消的话就好了. ^核实

用户: 我也这么认为. 另外, 也有一些网站是输入口令就能退订, 我觉得这个方法也不错.

---

2.3 访谈实践

2.3.1 如何设计访谈

漏斗形访谈框架, 先从职业, 兴趣等范围比较大的话题开始

2.3.2 访谈的地点, 设备, 人员

2.3.3 进行访谈

• 构建信赖关系

• 把握用户个人信息

• 把握用户使用情况

  请教 / 刨根问底 / 核实

  引出具体例子

  使用小道具

• 验证假设型访谈, 一般会安排在背景式访谈之后, 切忌放在背景式访谈中

---

? 案例: 访谈大纲

就办公自动化设备的使用情况进行访谈的大纲

用户的日常业务内容

因为什么开始使用这个办公自动化设备

使用特定办公自动挂设备进行的业务的具体内容

失败的教训

使用的窍门

其他相关业务等等

1. 引子

   • 寒暄 / 录音许可 / 相关信息公开授权 / 注意事项

2. 用户档案

   • 目的: 掌握业务内容
   • 问题示例: 首先, 能否请您介绍一下您的工作内容 / 公司概况 / 资历 / 专业知识技能等

3. 使用情况1

   • 目的: 掌握正常的使用情况

   • 问题示例:

     我看您在工作中似乎用到了 XX 办公自动化设备, 能否谈一下您平时是如何使用的? 什么时候 / 为了达到什么目的 / 在哪里/和谁一起使用等

     能都介绍一下最近一次使用 XX 办公自动化设备的情况呢?

     听说您有自己独创的使用方法, 那您是否有独特的心得体会呢?

4. 使用情况2:

   • 目的: 掌握特殊的使用情况

   • 问题示例:

     您在使用 XX 办公自动化设备时, 是否碰到过让您不知所措的情况呢? 能否介绍一下这段经历呢?

     您在使用 XX 办公自动化设备时, 肯定碰到过需要暂时中断, 先要处理其他事情的情况. 一般是处理什么事情呢? 暂时中断的话设备会怎么样呢?

     XX 办公自动化设备的功能里, 有什么事您偶尔使用或者根被没有用过的功能吗? 有您开始时会使用, 但慢慢地不会再使用的功能吗? 请您说一下原因?

5. 希望

   • 目的: 掌握明确的用户需求背后的使用情况

   • 问题示例:

     您对 XX 办公自动化设备是否有 ''如果能有这样的功能就好了‘’ , 或者 ‘‘这里如果能变成这样就好了’’ , 之类的想法吗? 为什么会这么认为呢?

6. 结束

   • 结束语 / 支付酬金 / 送客

---

2.4 情景剧本

2.4.1 文档化的必要性

有效的再现用户体验的场景, 支持设计团队讨论的工具 —— 情景剧本 (Scenario)

2.4.2 什么是情景剧本

scenario 就是用