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

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

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 快速迭代式测试和评估