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

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

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 就是用户使用系统或产品时的情景剧. 以写故事的手法, 吧用户使用系统或产品时的背景, 达到何种目的, 如何使用及其结果描绘出来.

写故事可以完整的描述用户在什么情况下, 采取了什么样的行动, 最终导致了什么样的结果. 可以用操作步骤示意图, 照片等补充情景剧本.

---

? 案例: 在线词典 Scenario

• 用户个人信息

  T 先生 (30 多岁的中年男性) , 是某软件开发公司的工程师. 由于工作性质, 需要了解最前沿的 IT 资讯, 而这些资讯主要来源于国外的网站和邮件新闻. 但是 T 先生的英语不太好, 两年前参加托业考试时, 才考了 600 多分. 虽说与专业有关的英语大概能看个明白, 但是想要精确地把握含义的话, 就要借助词典了.

• 使用在线词典的原委

  以前 T 先生主要使用电子词典. 虽然携带方便, 但输人不方便, 而且显示屏幕太小, 要一直翻页阅读, 这让 T 先生很不满意. 更加让 T 先生不能忍受的是, 很多 IT 相关的专业术语经常查不到.

  因此, 大概从两年前开始, T 先生就使用了免费的在线词典网站. 该网站不仅广泛收录了各专业的术语, 而且还及时收录了当前的流行语. 另外, 它的翻译并不生硬, 这点令 T 先生很满意. 因此, 无论是在公司还是家中的计算机里, T 先生都把该网站添加进了网址收藏栏, 以便在需要查询时随时访问. 现如今, 己经完全用不到电子辞典了 (T 先生的公司和家里都可以上网) .

• 使用场景 1: 简单使用

  如果是比较短的英文 (一页 A4 纸的长度) , T 先生一般都在电脑上阅读. 如果遇到了不认识的单词, 就新打开一个浏览器窗口, 通过书签访问在线辞典网站.

  有时 T 先生会直接在检索框内输人要查询的单词, 一般通过简单的复制粘贴查询单词, 因为如果手动输入不小心拼错单词的话, 就什么都搜索不到. 以前使用电子词典时, 就算是拼错了单词, 也会提示类似的单词一览以供选择. T 先生认为在这一点上, 电子词典倒是非常方便.

  确认了单词的含义后, 再通过任务栏切回到英文网站. 若再看到不认识的单词, 仍然需要切换到在线词典进行搜索. 但是, 如果要查找单词的数量比较多, 就要频繁地切换窗口, 使用上有点不方便.

• 使用场景 2: 复杂使用

  要阅读长篇的英文时, T 先生一般都会先把文章打印出来. 这样做, 一是因为在电脑上看太累, 其次是因为在电脑上阅读的话不能添加标注. 不懂的单词还是得通过在线辞典网站查询. 虽说 T 先生已经特别注意不拼写错误, 但是也会出现因拼写错误而查不到的情况.

  确认了检索结果后, T 先生会把他认为最合适的解释标注在英文单词旁的空白处. 因为在比较长的英文文章中经常会发生, 读了几段之后又重头读起的情况, 如果不把翻译的结果标注在文章里. 很可能下一次又要重新查一遍.

  尽管如此, 还是会发生同一个单词检索多次的情况. 因为对于一篇几十页的文章来说, 很难记住上一次查询的结果标注在了哪一页, 与其回头找, 不如重新查询一次比较快. 因此, T 先生认为, 如果在线词典服务能把之前查过的单词以列表方式显示出来的话, 那就方便多了.

• 使用场景 3: 特殊情况

  在写英文邮件时, T 先生偶尔也要使用日英辞典. 这时也是使用在线词典网站. 然而, 该网站默认使用的是英日翻译. 要想使用日英翻译, 就必须每次都转换一下设置. 因为 T 先生平时使用的都是英日翻译, 所以很多时候只有在检索结果为 0 时, 才注意到设置没有更改. 所以，T 先生认为如果能够自动识别语言种类的话就更好了.

---

2.5 分析情景剧本

2.5.1 情景剧本的写法

• 创作单个的小故事

  可以把一整块的内容整成单个的故事, 也可以把散落在笔记各处的内容整理成一个故事.

• 推敲情景剧本

  把小故事都写好之后, 就可以把他们组合成情景剧本了. 可以按时间排序, 可以更具相互间的影响调整顺序, 或者按照因果, 包含等关系, 把多个小故事合并成一个.

  一般一个 1 h 的访谈, 情景剧长度在 3~4 页 A4 纸, 需要时间一般为 2~3 小时.

2.5.2 测评情景剧本

邀请用户面对面再进行一次沟通, 请他本人来检查情景剧本

2.5.3 情景剧本的使用方法

完成情景剧本后, 要向全体成员公开. 让拥有不同背景的成员从各自的角度阅读情景剧本并提出修改意见. 同时, 在说明自己的创意时, 也可以参照情景剧本. 情景剧本中最有价值的信息就是 “货真价实的任务” 和 “真正的用户需求” .

• 货真价实的任务

  设计人员根据主观臆想产生的是假任务, 真正的任务可以从情景剧本中发现

  使用词典阅读英语短文

  使用词典阅读英语长文

  使用词典写英文邮件

  “查询单词含义并不是真正的任务” , 因为即使做查询一个列表的单词的含义的测试, 也不会发现这个在线词典真正存在的问题.

• 真正的用户需求

  即使没有用户明确说明, 根据上下文也可以推断出的必备的需求 (隐藏的需求) .

  用户用打印网页的功能时, 不经处理打印的话, 就会把导航栏也一起打印出来, 或者出现网页过宽, 与打印纸大小不符等情况. 用户可能并没有对此表示特别的不满, 但是也应该注意到此类需求.

2.5.4 探索用户需求

1. 分解

   根据用户行为, 场景等的切换进行情景剧本的分解. 注意撰写情景剧本时候, 不要在单个句子中包含用户的多个行为或要求.

2. 分析

   从分解后的段落中寻找用户需求. 理解用户的行为在整个情景剧本中具有什么样的意义, 推导用户的潜在需求. 注意不要把用户需求 (What) 和解决方案 (How) 混为一谈. 用户需求都是抽象的表现, 需求中不应出现具体的功能名称或者界面元素.

   网上商城的情景剧本中, “网站上没有公开的信息如果能通过邮件来咨询就好了” , 并不是真正的需求.

   真正的需求是 “希望尽快获取网站上那些没有公开的信息”.

3. 思考

   思考可以满足用户需求的妥善方案, 把所有满足条件的方案整理成列表.

2.5.5 分析情景剧本的好处

2.5.6 专栏: 角色 (Persona)

Persona 是目标用户形象, 是从调查结果中挖掘出来的, 可以避免被橡胶用户耍得团团转.

• 进行访谈

  访谈对象要尽可能覆盖预想的用户群, 一般 20~30 人左右.

• 把用户分组

  根据使用该产品的目的或需求, 在组织或团体里的职责, IT 技能, 行为相似性等, 把用户分组. 一般 3~7 组, 每个组取一个能代表其特征的组名.

• 定义代表

  找到该用户组中, 最具有代表性的用户, 然后在该用户体验的基础上, 追加同组其他用户的体验. 也就是说, 综合组内各个成员, 创造出一个 “混合体” .

• 添加个人信息

  加上姓名, 年龄, 照片等个人信息, 给人以逼真感.

• 选取主角:

  一个项目可能会有 3~7 个角色, 但是我们要给这些角色以不同的优先权. 角色的优先权因项目而异. 如果各个角色刚好和细分市场一致, 那么市场价值最大的就是主角; 如果过项目标准是谁都能使用, 那么技能水平最低的就是主角.

---

? 案例: 在线词典用户需求

---

第三章 原型

3.1 什么是原型

3.1.1 原型的作用

3.1.2 高保真和低保真

低保真原型不是所有部分都做得粗枝大叶, 和测试直接相关的部分要花心思, 要能测试. 比如, 如果是为了检验在线商城购物车的原型, 就必须完全模拟购物步骤之间的跳转和出错的提示.

3.1.3 T 原型

水平原型, 也被叫做 "浅式原型 (Shallow Prototype) " , 只需要制作网站首页和第一层链接页面.

垂直原型, 也被叫做 "深式原型 (Deep Prototype) " , 只是具备某一项功能的原型.

把水平原型和垂直原型组合在一起, 就是 T 原型.

3.1.4 奥兹国的魔法师 (Wizard of Oz)

让人躲在背后代替电脑做动作, 但是从用户的角度看上去好像是系统在运作的方法, 就是 Wizard of Oz.

3.2 原型的制作方法

3.2.1 制作工具

3.2.2 制作的重点

要让所有的链接和按钮都可以点击, 一些不可用的页面可以代入假页面 “目前该页面不可用, 请返回上一页” .

需要具有高保真度的元素:

• 界面切换 (顺序, 数量)
• 界面元素互相位置关系
• 文本连接的内容以及按钮上文字的内容
• 在界面中现实的指示性文字的内容
• 需要输入的数据项目及其格式
• 操作相关的图标设计

3.2.3 由谁来制作

3.3 卡片分类法

3.3.1 层次结构设计

在划分层次结构时候往往会遇到问题, 这时候就需要用卡片分类法 (Card Sorting) . 卡片分类法有封闭式 (Closed) 和开放式 (Open) 两种.

3.3.2 封闭式卡片分类法

也叫做带有目录的卡片分类法. 白板上已经有了各个种类的名称, 用户需要将记有具体素材的卡片贴到各个种类下面. ^{注意在用户操作结束后, 提问用户为什么要贴在该种类下面}

同时用户是如何移动卡片的, 卡片的移动轨迹也很重要. 如果到最后都未能决定放在哪个分类下, 说明现有的分类不能覆盖所有信息的种类, 或者本该相对独立的两个分类仍存在某种关联.

3.3.3 开放式卡片分类法

也被称为不带目录的卡片分类法

• 聚类分析

  使用距离矩阵 (差别矩阵) 把样本按空间距离由近到远的顺序结合, 从而产生聚类的多变量分析方法. (必须使用统计软件) 聚类分析后就能做出表示数据层次结构的树形图了.

  

• 分类合并

  分类合并是合并用户取的分类名的分析方法, 也就是把含义相同的分类名称合并.

  比如, 某个用户把相关素材卡片归类后, 命名为 “产品信息” , 其他用户可能命名为 “产品” 或者 “商品” 等, 可以把这些含义相同的分类名合并.

3.3.4 Delphi 卡片分类法

开放式卡片分类法可以给信息设计带来启示, 但是并不能直接用做设计. 需要通过反复的开放式和封闭式卡片分类法达到逐渐提高成果精确程度的目的. 这样成本高, 所以引入了 Delphi 卡片分类法. Delphi 法也可以用于团队内部的讨论工具, 让大家快速统一意见.

基本流程:

1. 制作构造信息的原型 (种子) , 种子产生的影响很大, 尽量安排经验丰富的设计师设计种子
2. 请多位用户分别按照自己的意愿在原型上修改
3. 持续进行 1~2 步骤

第四章 产品可用性评价方法

4.1 什么是评价

4.1.1 总结性评价和形成性评价

• 总结性评价 (summative Evaluation)

期末测验, 为了打分, 体现学习成果

性能测试法: 安排几十个用户使用界面, 检验目标达成率 (有效性) , 所需时间 (效率) , 满意度 (满意度) ; 评价结果一般以 “目标达成率: 55%” , “平均达成时间: 5 分 30 秒” , “主管满意度: 2.8 分 (5 分制) ”

一般在设计前或设计后使用

• 形成性评价 (Formative Evaluation)

课堂后的练习, 目的是为了改善, 而不是为了打分

发声思考法

会在产品设计过程中反复使用

4.1.2 分析法和实验法

• 分析法 (Analytic Method)

也被称为专家评审 (Expert Review) , 让产品可用性工程师及用户界面设计师等专家基于自身的专业知识和经验进行的评价

缺点: 主观, 评价结果是假设的

优点: 时间少, 费用少, 评价范围比较广, 设计初期也可以评价

• 实验法 (Empirical Method)

手机货真价实的用户使用数据, 比如用户测试法, 问卷调查等

缺点: 时间长, 花费大, 评价范围窄, 为了做评价必须做原型

优点: 客观, 评价结果是事实

• 分析法和实验法互补

设计初期阶段, 没有原型产生, 只能用分析法; 另外用户测试之前, 自豪先用分析法进行简单评价, 整理出用户测试时应该要评价的重点和需要重点观察的部分

4.2 产品可用性检验

Usability Inspection

4.2.1 启发式评估

分析法是评价人员基于自身专业只是及经验进行的评价, 评价标准很模糊. 为了让评价有客观性, 就出现了各种各样的指导手册. 依据指导手册进行的评估就是启发式评估 (Heuristic Evaluation) .

4.2.2 启发式评估十原则

• 尼尔森的启发式评估十原则 (10 Heuristic)

  中文译文 [掘金网]

  文章与视频 [尼尔森网]

• 经典用户界面交互设计黄金 8 法则 (Eight Golden Rules of Interface Design)

• IBM 设计原则 (Design Principles)

• 国际标准 ISO 9241 Part 10: 对话原则 (Dialogue principles)

4.2.3 启发式评估法的实施步骤

1. 招募评价人员

至少3个专家: 比如产品可用性工程师, 用户界面设计师 (不可以是界面设计者本人)

2. 制定评价计划

事先制定好评价界面的哪些部分; 依据那个原则进行评价;

3. 实施评价

每个评价人员单独进行评价. 以网站为例, 既可以从首页开始, 按层次依序访问; 也可以假定几个任务, 然后再执行任务的过程中发现问题; 也可以在输入项中输入一些异常值; 或者改变使用环境 (界面分辨率, 网络速度, 不同的浏览器等)

尼尔森推荐, 第一次检查界面的流程是否正常, 第二次详细检查各个界面是否存在问题

一般 2~3 天内可以完成单独的评价, 网站一般一个小时评价一个页面, 手机大概一小时评价一个任务

4. 召开评价人员会议

一般持续 3~4 个小时, 首先请评价人员代表汇报评价结果, 其他评价人员一边听报告, 以便随时就自己是否也发现了相同的问题或者发现了其他问题发言.

5. 总结评价结果

产品可用性问题列表, 配上界面截图, 界面流程图等, 形成简单的报告

4.2.4 启发式评估法的局限性

• 查出的问题过多

• 专家费高

• 注意事项

  不以个人偏好, 而应以理论依据进行评价. 可以不拘泥于启发式评估原则, 但必须明确评价遵照的依据

  评价的目的不是单纯的挑错, 更应该给出一些建议

  当出现意见不一致时, 与其把时间浪费在争论上, 不如使用实验的方法的出正确的结论

4.2.5 专栏: 认知过程走查法

基于人类的认知模式进行检验的方法——认知过程走查法 (Cognitive Walkthrough).

认知过程走查法是基于界面流程图和用户认知模型之一的 “探索学习理论” 寻找问题. “探索学习” 指的是事先不阅读用户手册, 不接受任何相关培训, 在使用的过程中学习使用方法.

用户探索学习主要包含四个步骤:

1. 设定目标: 设定用户要达成什么目的 (任务或子任务)
2. 探索: 用户在用户界面里探索究竟该做什么操作
3. 选择: 用户为了达到目的, 选择他认为最合适的操作
4. 评价: 用户分析操作后的系统反馈, 判断任务是否正常进行.

让评价人员 (从用户的角度出发) 回答以下四个问题, 来发现导致用户混乱或使用户产生误解的地方:

1. 用户是否知道自己要做什么?
2. 用户在探索用户界面的过程中是否注意到操作方法?
3. 用户是否把自己的目的和正确的操作方法关连到一起了?
4. 用户能否从系统的反馈中判断出任务是否顺利进行?

? 案例: 呼叫转移认知过程走查

呼叫转移的正确步骤:

1. 用户在与对方通话中的状态下, 按住 CLR 键 > 此时屏幕上显示 “通话保持中” .
2. 用户拨出要转移的内线号码 > 此时屏幕上显示内线号码并发出拨号音
3. 用户在与内线通话中的状态下, 按 HLD 键 > 转移操作完成, 返回待机界面

4.3 什么是用户测试

4.3.1 用户测试体验记

惠子的故事

4.3.2 用户测试的概要

4.4 具有代表性的测试方法

4.4.1 发声思考法

Think Aloud

观察用户发言与操作的重点, 要落在

1. 有效性问题: 用户是否独立完成了任务
2. 效率问题: 用户在完成目的的过程中, 是否遇到了不知所措的情况, 或者需要用户反复考虑, 做了很多无效操作的情况.
3. 满意度问题: 用户是否有不满的情绪, 是否又让用户不舒服的界面

注意并不局限于发现 “有效性问题, 效率问题, 满意度问题” , 更要弄清楚为什么会导致上述结果.

4.4.2 回顾法

Retrospective Method

对用户的提问在操作完成之后进行, 但是缺点比较多. 一般如果在操作过程中, 向用户提问会对操作产生较大的影响时, 采访人员就会在操作完成之后, 使用回顾法补全想要的信息.

4.4.3 性能测试

Performance measurement

性能测试属于总结性评价, 原则上会安排在项目前 or 项目后. 性能测试参与人员较多, 至少40~60人. 一次性能测试会测试多个用户界面, 通过对比竞争产品 / 多套方案 / 改版前后方案的数据, 就能进行客观评价了.

一般评估一下几个方面:

• 有效性: 任务完成率, 有几成用户可以独立正确地完成任务

• 效率: 完成任务的时间, 操作步骤数, 鼠标点击数

• 满意度: 主观评价, QUIS, SUMI, WAMMI 等问题模板 >

用户调研之问卷制作指南 [标点符]

用户交互满意度量表 QUIS [标点符]

SUS 量表与问卷设计

4.5 用户测试的基础理论

4.5.1 产品可用性的理论基础

如果想要做用户测试, 至少先要做出值得测试的界面 (有原型, 做过启发式评估)

4.5.2 用户测试的参与人数

尼尔森的 5 人能发现 85% 的问题的学说

但是该学说也存在漏洞, 没有反应问题的严重程度, 解决了这5个人发现的问题, 难道就能说该界面达到了 85 分了吗?

4.5.3 专栏: 比较调查是失败的根源

A 有 40 个问题; B 有 60 个问题, C 有 30 个 问题. C 一定是最好的么? 有可能 3 个都是 0 分

4.6 用户测试的实践基础

4.6.1 招募

急募! 关于食谱的访谈招募参与者!

40岁左右的女性, 平时会做饭, 平时会使用电脑, 使用智能手机的人优先

地点, 秋叶原; 日期和时间, 下周内您方便的时间; 所需时间, 约一小时; 酬金 600 人民币

联系方式: XXXXXXXXX

4.6.2 设计测试

设计任务 (Task)

访谈指南 (Interview Guide)

试点测试 (Pilot Test)

4.6.3 实际操作

4.6.4 分析与报告

记录了用户行为和发言的资料称为协议 (Protocol) , 记录完成收, 挖掘其中的可用性问题, 分类整理, 并判断问题的严重程度

4.6.5 时间与费用

招募: (2 周) ; 同时进行测试设计 (1 周)

实际测试: 2~3 天 (2 人一天)

分析和报告: 1~2 周

费用: 2 万人民币 / 人 / 小时

4.7 推荐 DIY 用户测试

4.7.1 轻量化趋势

敏捷开发, 1~4 个星期为单元进行短期开发迭代

4.7.2 DIY

4.7.3 二八定律

把注意力放在决定了 80% 价值的 20% 的元素上

4.7.4 DIY 基本原理

六度空间原理: 充分利用人脉

利用日常用品

原始的分析方法: KJ 法 (Affinity Diagram)

对话高于报告

4.7.5 用户测试的失败案例

4.7.6 专栏: 低成本用户测试的发展

Steve Krug

<点石成金: 访客至上的网页设计秘籍> <Don’t make me think>

<妙手回春: 网站可用性测试及优化指南> <\Rocket Surgery Made Easy>

• 定期 (每月 / 每日一次), 反复地进行小规模 (3 个参与者) 的测试
• 要求相关人员参与观察用户测试
• 解决方案永远没有最好, 只有更好

第五章 用户测试实践篇

5.1 招募

5.1.1 招募准备

具有代表性的用户, (被认为) 有能力使用该产品完成任务, 一般可以将招募条件精简到 30 字左右

以下举例:

[二手车网站] 正在考虑买二手车的 20 岁左右的青年男女

[婚恋网站] 准备结婚, 且在市中心工作的未满 35 岁的女性

[防盗服务] 孩子是初中生, 住在郊区独栋楼房的全职家庭主妇

[车载导航仪] 开低档或中档汽车, 住在郊区的中老年人

5.1.2 利用人脉

5.1.3 抓住一切机会

5.1.4 招募的诀窍

5.2 设计 DIY 测试

5.2.1 设计任务

任务示例:

[DVD 录像机] 收看录好的电视节目

[税务网站] 做最后的税务申报

[交通换乘app] 搜索公交车, 地铁等的最后班次

[ 商品活动信息网站] 申请参加某化妆品的活动

[多功能数字一体机] 准备 10 分会议资料的复印件

[餐饮信息网站] 搜寻可以开年会的饭店并预约

[车载导航仪] 去某游乐园

[保险公司网站] 汽车保险的预估

[保健设备] 确认三个月来体重的变化

• 把精力锁定在主要任务上

可以从产品的研发目的角度出发, 来理解主要任务是什么

• 从用户的角度出发

某房地产信息网站的开发团队把 “购买一手房” 当作了任务, 但是实际上用户是不可能在网站上买房的, 网站主要是为了手机房产信息, 查看自己感兴趣的户型资料等等, 之后用户会亲自看方, 在和售楼处的销售员当面沟通后再购买. 测试任务可以是 "申请参观自己感兴趣的房产” .

• 明确起点和目标

用户测试中最重要的地方就是 “用户是否可以完成任务”, 因此要明确 "目标” 是什么.

• 剧本化

实际使用时, 用户会有自己的离有和目的, 再测试中, 要追加一些假设的情况背景, 把任务润色成故事. 比如, 假设你所工作的部门要召开一次欢送会, 刚好有你来负责准备工作, 请使用该网站寻找可以开欢送会的地方.

5.2.2 准备实际检查工具

5.2.3 制作访谈指南

• 测试大纲

序曲: 录像许可, 签订信息保密协议 NDA

事前访谈: 询问用户背景及任务相关内容

事前说明: 向用户说明发声思考法, 并对设备做简单的操作练习

观察任务的执行

事后访谈: 感想, 主观评价, 期望

尾声

• 访谈示例

5.2.4 进行试点测试

可以找同事或者朋友测试, 目的是为了发现用户测试中的问题. 实际用户测试时, 所用时间大概为 Beta 测试的 1.5 ~ 2.0 倍.

5.2.5 专栏: 其他与任务有关的内容

• 简易任务的设计方法

任务必须要有目标, 很多时候, 定义目标就是定义目标页面. 比如用手机发短信, 目标页面就是显示 “短信发送成功” 的页面. 而任务就可以在该目标页面之前加上 “请” 字, 在这里任务就可以设置为 "请发送短信” .

• NG 任务集

请您在接下来的时间内, 随便使用这个网站

任务必须要有目标

今天天气特别好, 您的心情也很好吧, 这种心情特别适合…

用户测试是要设置环境 (场景, 前后关系) , 但是心情和环境不同.

请 “定位” 一下店铺

不可以使用用户界面术语

请先输入本文, 然后以短信形式发送给 A 先生

任务应该只包含最终目标, 不可以包含完成的步骤

请阅读商品 A 的说明书, 如果对它感兴趣的话, 请购买它

同样, 心情是非常暧昧的东西, 作为任务, 只要指示 “请购买商品 A” 就足够了.

• 任务的本质

5.3 简易实验室

5.3.1 测试地点

5.3.2 测试设备

5.3.3 录像方法

Camtasia Studio

Silverback

AmaRecCo

5.3.4 专栏: PinP

在图像中再显示一个小图像 Picture in Picture (PinP)

5.4 访谈

5.4.1 不提问, 不回答

用户问 “这个按钮可以按吗?” , 采访人员可以反问 “您觉得可以吗”

5.4.2 实况转播

您现在在看什么?

您现在在想什么?

您现在在做什么操作?

你觉得接下来怎么做比较好?

这是您想要的结果吗?

您之前觉得会变成什么样子?

您之前为什么会这样想?

您现在觉得怎么样?

5.4.3 事后询问

您刚刚在 XX 界面做了 XX 操作, 能说一下为什么这么做吗?

其实就是回顾法

5.5 观察

5.5.1 增加 “目击者”

尽量让有话语权的人来观察用户的操作, 至少让每个观察人员参加三场以上的测试. 如果只参加了一场, 很容易只根据着一位用户的言行决定产品的设计, 这还不如完全不参加观察.

5.5.2 观察的礼仪

打招呼, 不注视, 不发声, 不介入

5.5.3 观察的技术

用户测试中, 只需要观察 “在什么页面发生了什么” , 以及当时 “用户 说了什么” 就足够了. 另外, 观察不是分析, “应该把这个标签颜色改的更亮一些” , 这是分析的结果, 而不是观察的结果.

5.5.4 专栏: 用户真的喜欢优惠吗

用户测试的参与者是从很多注册会员中挑选出来的, 对他们而言, 网络就是赚小钱的地方. 这些人平时就希望能从互联网上获得尽可能多的好处, 即使是执行任务, 这种想法也不会改变.

用户测试中, 不能对用户言听计从, 因为意见会因环境的变化而变化, 而且很容易受到个人属性的影响. 不要因为 5~6 个用户说 “我对优惠信息抵抗力很弱” , 就在自己的网站里堆满了优惠广告.

5.5.5 专栏: 发声思考的理想与现实

5,6 分析

5.6.1 张贴

• 记录下来的内容不应该是所谓的 “注意点” , 而是观察到的 “事实”
• 从用户的角度出发进行记述

5.6.2 映射

项目界面打印出来贴在墙壁上, 再把观察到的数据贴在对应的位置上

某个特定页面里贴的卡片特别多, 那肯定是有问题的

5.6.3 影响度分析

一次的测试中, 最多罗列出 10 个要解决的问题点

——史蒂夫 . 克鲁格

• 问题性质

从 “效果问题 > 效率问题 > 满意度问题” 的顺序来测评问题性质

• 发生频率

一般通过 “一个人, 几个人, 几乎所有人” 来划分, 比如 5 人的例子可以划分为: 1 人, 2~3 人, 4~5 人

5.6.4 专栏: 任务完成状况一览表

可以发现哪些任务被发现了很多问题

◯ : 用户独立完成任务, 且其中基本为发生混乱或绕了弯路.

▲ : 虽然完成了任务, 但是期间饶了弯路, 或者被观察到在操作过程中又出现困惑的情况, 另外, 也包含用户表达了强烈不满的情况.

× : 用户被认为未能独立完成任务.

5.7 再设计

5.7.1 交谈比文档更值得重视

敏捷开发宣言: 工作的软件高于详尽的文档

最具有效果并富有效率的传递信息的方法就是面对面交谈. 但是可以做一份 "最低限度” 报告, 具备任务完成一览表, 映射结果清单, 附带优先级的问题点列表等必要元素, 大概 2~3 页 A4 纸, 最后添加上映射结果的照片.

5.7.2 解决问题

有 10 个问题并不意味着要有 10 个对策. 如果能深入分析每个问题的内部构成, 就能够做到一个对策解决多个问题点.

5.7.3 反复设计

设计解决方案 > 测试 > 迭代设计解决方案 > 测试 > 迭代解决方案 > 测试 > …

5.7.4 专栏: 小变更带来大成果

• IME 手写文字输入
• 倾斜 13 度
• 海外邮寄的 “您的” 和 “他们的“

5.7.5 专栏: 头脑风暴法

严禁批判, 自由奔放, 量比质重要, 欢迎搭便车

可视化, 严禁跑题, 每次一人发言

5.8 隐私与伦理

5.8.1 个人信息保护

5.8.2 伦理上的责任

5.8.3 专栏: 不要轻易测试

第六章 超越 UCD, 走向敏捷 UX 开发

6.1 推荐非瀑布型 UCD

6.1.1 瀑布型与敏捷开发流程差异

类型 A : 各个步骤按顺序进行

类型 B : 各个步骤以首位部分迭代的方式进行

类型 C : 多个步骤以重叠的方式同时进行

6.1.2 沟通方式的差异

6.1.3 “慢慢地” 差异

6.1.4 敏捷开发与 UCD

6.2 敏捷开发的潮流

6.2.1 敏捷 UX 简史

6.2.2 敏捷 UX 的原则

• 由内至外

不开发多余的功能, 从对用户最有价值的核心功能开始开发, 慢慢扩展到可选功能上

• 平行推动

开发和 UX 设计同时完成, 平行轨道法

• 轻装上阵

减少复杂的流程和大量的文档

6.2.3 敏捷 UX 的理论基础

敏捷开发理论

UCD : 用户为中心的设计

UCD : 使用为中心的设计 <面向使用的软件设计> , 从用户使用案例 (用户故事) 到用户界面的设计流程理论

敏捷开发 + 用户为中心的设计 + 使用为中心的设计 = 敏捷 UX 开发模式

6.3 使用敏捷 UX 开发

1. 思考产品的概念是什么 (为了谁, 做什么)

可以先做个简单的调查, 游击调查 (Guerrilla Research) . 记住绝对不要问 “您想要什么” , “您需要什么” , 而应该深入探求 "有什么地方让您困惑”

2. 有了范围之后, 可以研究解决方案了

头脑风暴, 寻找新的创意

游戏风暴 (Game Storming)

3. 立项前的概念测试

立项前, 一般要对创意进行验证. 一般常用的方法是, 制作故事板和模型, 进行投票, 或者在网站上投入家的产品广告确认用户反应. 另外在创意达到用户认可的程度之前, 需要反复进行调查, 构思, 检验.

Elevator Pitch

4. 组织团队

敏捷开发一般都是自组织化的多功能型团队, Scrum 团队

5. 建立临时虚拟角色 (Pragmatic Personas)

敏捷开发的 UX 项目并不具备制作正式 Persona 的充分数据, 因此, 先基于已知信息来定义用户角色, 之后再对该用户进行拟人化, 生成临时的虚拟角色

6. 通过用户故事 (User Story) 定义需求

以虚拟角色为主语, 用类似 “XX 是谁, 他想干什么, 出于什么目的” 这样的短文章, 把需求分割成许多小的特性, 以小故事的形式记录在卡片上

7. 预估各种各样用户故事的作业规模

不使用具体的 (人/月) 作为计量单位, 而是用故事点 (Story Points) 来衡量工作量的多少, 故事点是一个相对度量单位，用于表示完成某项工作所需的所有工作量的估算结果.

预估工作主要使用计划扑克的游戏形式来进行的.

什么是故事点 [Scrum中文网]

什么是计划扑克 [archimetric]

其他敏捷估算的方法 [简书]

8. 决定用户故事的实现顺序

利用用户故事映射 (User Story Mapping) 二维表, 综合考虑各功能之间的相互作用, 市场变化等与产品相关的各种因素, 来做出决策

用户体验地图完全绘制手册 [优设]

用户故事地图之起床故事 [简书]

9. 开发

1~4 周左右的迭代期, 迭代期内尽可能实现有限的用户故事, 开发团队的作业进展情况会在任务面板 (Task Board) 上更新. 同时用户界面应与与开发同步进行, 可以利用草图板 (Sketch boards). 制作好原型之后, 应立即利用用户测试进行检验

6.3.5 专栏: RITE 法

Rapid Iterative Testing and Evaluation 快速迭代式测试和评估

mg-BowSIq59-1570968118541)]

4. 组织团队

敏捷开发一般都是自组织化的多功能型团队, Scrum 团队

[外链图片转存中…(img-zCAY6gyv-1570968118542)]

5. 建立临时虚拟角色 (Pragmatic Personas)

敏捷开发的 UX 项目并不具备制作正式 Persona 的充分数据, 因此, 先基于已知信息来定义用户角色, 之后再对该用户进行拟人化, 生成临时的虚拟角色

[外链图片转存中…(img-WcCEVwD6-1570968118543)]

6. 通过用户故事 (User Story) 定义需求

以虚拟角色为主语, 用类似 “XX 是谁, 他想干什么, 出于什么目的” 这样的短文章, 把需求分割成许多小的特性, 以小故事的形式记录在卡片上

[外链图片转存中…(img-60Xx7cHY-1570968118544)]

7. 预估各种各样用户故事的作业规模

不使用具体的 (人/月) 作为计量单位, 而是用故事点 (Story Points) 来衡量工作量的多少, 故事点是一个相对度量单位，用于表示完成某项工作所需的所有工作量的估算结果.

预估工作主要使用计划扑克的游戏形式来进行的.

[外链图片转存中…(img-dFdVIQ1Q-1570968118545)]

什么是故事点 [Scrum中文网]

什么是计划扑克 [archimetric]

其他敏捷估算的方法 [简书]

8. 决定用户故事的实现顺序

利用用户故事映射 (User Story Mapping) 二维表, 综合考虑各功能之间的相互作用, 市场变化等与产品相关的各种因素, 来做出决策

[外链图片转存中…(img-Z4OAy9oy-1570968118545)]

用户体验地图完全绘制手册 [优设]

用户故事地图之起床故事 [简书]

9. 开发

1~4 周左右的迭代期, 迭代期内尽可能实现有限的用户故事, 开发团队的作业进展情况会在任务面板 (Task Board) 上更新. 同时用户界面应与与开发同步进行, 可以利用草图板 (Sketch boards). 制作好原型之后, 应立即利用用户测试进行检验

[外链图片转存中…(img-hQKD6kHO-1570968118546)]

[外链图片转存中…(img-jMZe8ajT-1570968118546)]

[外链图片转存中…(img-iUuOYNx1-1570968118547)]

[外链图片转存中…(img-5m1mzPuM-1570968118548)]

6.3.5 专栏: RITE 法

Rapid Iterative Testing and Evaluation 快速迭代式测试和评估