“用户体验及可用性测试”前三章：读书笔记

本书由日本的一位相关领域专家樽本徹也著，陈啸译。特整理了简要的读书笔记，希望大家1小时左右即可了解本书的核心内容。

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

1.1UX和UCD

1.1.1体验的价值：简而言之，最值钱的就是“体验”了。

1.1.2UX的构成：UX（User eXperience，用户体验），由战略层、范围层、结构层、框架层和表现层这五层组成。

1.1.3UX的实现方法：UCD（User Centered Design，以用户为中心的设计），UCD是一种设计思想，UCD流程为调查（把握用户使用情况）、分析（从使用状况中探寻用户需求）、设计（设计出满足用户需求的解决方案--制作模型）、评测（评测解决方案--使用模型）、改进（对评测结果做出反馈，改进解决方案--改进模型）、反复（反复进行评测和改进）。

1.1.4UCD的要点

一、流程的质量：只有遵循优秀的流程，才能做出优秀的界面；

二、螺旋上升的设计流程：一开始就注定会是一个“螺旋上升式”的开发流程（为了在最短时间内，以最低开销进行反复设计，我们可以从手绘的用户界面开始，一边逐渐完善用户界面，一边反复进行评测和改进）；

三、用户的参与：必须要有真实用户参与。

专栏：UX的国家标准（1999年，国际标准ISO 13470；2010年修订为ISO 9241-210，只是定义了流程的框架层，内容非常简洁，主要增加了UX的定义、以人为中心的设计的7个适用依据、以人为中心的设计6项原则、以人为中心的设计活动）

1.2产品可用性 ≠产品易用性

1.2.1产品可用性可有可无吗：Usability不是易用性，而是可用性。

1.2.2根本没法用的产品

乱七八糟的搜索引擎、繁琐的订单页面、没法后退的网站等，正因如此，杰柯柏.尼尔森博士说道："能左右互联网经济的正是产品可用性。”交互系统的用户界面设计确实是一件非常复杂的工作。

1.2.3产品可用性的定义：特定的用户在特定的使用场景下，为了达到特定的目标而使用某产品时，所感受到的有效性、效率及满意度。

有效性：指的是用户能够达成自己的目标。

效率：用户必须做无用功，就能以最短路径达成目的。

满意度：即使有效性和效率两方面都没有大问题，也要从更深层次来考虑，即有没有给用户带来不愉快的体验。

比较现实的一个做法是，在权衡问题严重性的同时，首先要解决有效性问题，然后在时间和成本允许的情况下，尽量解决效率和满意度的问题。

1.3产品失败的原因：很遗憾的讲，大半的精力都浪费在了不切实际的讨论和活动上。

1.3.1橡胶用户：所谓橡胶制品的隐喻就是简单可变。导致产品不能用的常见原因之一就是“用户定义失败”。

1.3.2产品使用背景：产品使用背景是产品可用性的关键因素。

例1：转接非常麻烦的公司分机

例2：销声匿迹的BP机

例3：不会用到的重置按钮

不管你熟知多少设计原则，一旦理解错了产品使用背景，就不仅仅是没有意义这么简单了，反而给用户添了麻烦。

1.3.3用户体验的点与线：用户界面的作用就是引导用户达成自己的目标，而用户在达成目标的过程中肯定存在着一条路线，在这条路线上但凡存在着一个不能通过的关卡，就会使用户达不成目标。必须有一种能够清除所有问题的方法。

1.4UCD的最新四原则：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徒弟的思想准备：自然访谈。

基本技能：请教（进入正题）、刨根问底（问清楚）、核实（复述）。

访谈的注意事项：1、不能被觉察出你是专家；2、不要去验证你的假设；3、不要在无效的问题上纠缠。

2.2.3选择师父的方法

师父的条件：技术和经验比较重要。

要找多少位师父：每一个用户群组为5-6人，用户群一般设定为3-6组。

招募方法：1、调查公司的样本库：寻找符合条件的志愿者；2、人脉：利用人脉，拜托朋友介绍符合条件的人。

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分析情景剧本的好处：情景剧本再现了用户实际体验，记载的全部是事实；情景剧本是可逆的（可以反复分析研讨）；设计团队可以从失败中学到更多的东西。

专栏：角色

假想的用户角色

如何设计角色：1、进行访谈；2、把用户分组；3、定义代表每个分组的用户形象；4、为每个用户形象添加逼真的个人信息；

主角：让人拿捏不准的临时角色（临时角色存在的问题；临时角色的用途；临时角色是否真的具有实用性）；什么是敏捷型角色（正因为敏捷开发模式，所以依据数据创建的角色才更加适用）；

第3章原型

3.1什么是原型

3.1.1原型的作用

实验模型：制作模型的好处就是可以灵活地应对设计中的错误以及客户提出的新需求。

试用品：让用户试着用一下。

3.1.2高保真和低保真：几乎完全按照实物制作就是高保真；反之，粗枝大叶制作就是低保真。

3.1.3T原型：广度和深度兼备的原型就是T原型。

3.1.4奥兹国的魔法师：只要肯花心思，制作原型所需的时间和金钱肯定可以大幅缩减。

3.2原型的制作方法

3.2.1制作工具：日常使用的软件工具可以用来制作原型。

纸质界面：最简单的就是纸了。

无形的原型：只要能够做出可达成设计团队目标的最低限度的界面，随便用什么工具都可以。

3.2.2制作的重点

1、不要忘记做假的页面。

2、需要具有高保真度的元素：如果希望用户执行任务并从中发现问题，就必须高仿那些影响用户判断的元素。

3、保真度较低也无妨的元素：原型中的内容是没有任何价值的。

3.2.3由谁来制作

是否一定要做出完美的原型：重点要把精力集中在如何解决问题上。

制作原型所需的技能：绝大多数原型制作并不需要多高深的艺术素养或专业的程序设计技术，深入理解用户需求，测试设计所需的逻辑能力，不局限于已有概念的发散思维能力，这些才是设计师更需要掌握的。

专栏：用PPT来制作原型（可交互的连环画；非常适合嵌入式应用）

3.3卡片分类法：制作原型方法之一

3.3.1层次结构的设计：有封闭法和开放式两种。

3.3.2封闭式卡片分类法

封闭式卡片分类法步骤：将产品一览、公司简介等目录名称记录在有颜色的卡片里，贴在白板上；把具体素材的名称和简介记录在白色的卡片里；把这些白色卡片交给用户，请他们按照自己的理解贴在对应种类下面；用户贴卡片时，应该问他们为何要放在该种类下面。

也可以在线调查：网络问卷的方式进行。

3.3.3开放式卡片分类法：封闭式主要用户评测及改善设计团队的创意，开放式分类法更具有探索性。

聚类分析：使用距离矩阵把样本按空间从近到远的顺序相结合，从而产生聚类的多变量分析方法。

分类合并：把含义相同的分类名称合并，就更容易统计出结果了。

3.3.4Delphi卡片分类法

什么是Delphi法：针对技术预测、趋势预测等定量预测难以实施的问题，通过反复收集专家的意见和反馈，把结果控制在一定的范围内，从而达到提高预测精准度的方法。虽说刚开始时会出现各种各样的意见，但在看见别人的回答后会修正自己的部分意见，因此会逐渐把结果归纳到一定范围内。

Delphi卡片分类法的优点：一开始就有种子，大幅减少参与人有的力量；种子产生的影响实在太大，因此应尽量安排经验丰富的信息设计师来设计种子。

“用户体验及可用性测试”前三章：读书笔记相关推荐

用户体验与可用性测试_可用性作为用户体验的原则
用户体验与可用性测试 Every UX Designer has his views and best practices. We all have a guide book created thro ...
怎么进行用户体验与可用性测试？
一.以用户为中心的设计概论 UX & UCD User Experience用户体验:是指用户在使用或预计要使用某产品,系统及服务时,产生的主观感受和反应.由战略层.范围层.结构层.框架层. ...
windows 程序设计第三章读书笔记（上）
娘的,今天晚上在阳台做饭把水管一脚踢爆了,水流到下面的住户的阳台,让个老娘们把我骂了一顿,本着做错事的原则,我装的很绅士还说了个对不起,擦,真是条纯汉子,能屈能伸. 大爷,别看我年轮小,我都给总结了, ...
Android深度探索--HAL与驱动开发----第三章读书笔记
Git--源代码管理软件,Git功能十分复杂,我们需要完成的功能有:创建版本库,提交源代码,创建分支,向远程服务器提交源代码,从远程服务器获取源代码等.而本章的学习内容就是掌握如何使用Git从源代码托 ...
R数据科学第三章读书笔记和习题
这篇文章只是记录个人理解,有时间会写第五章EDA(探索性分析部分) 概述 dplyr包在r语言中是用来整理数据集,以便数据更容易处理. dplyr中有5个核心函数,分别是按值筛选观测 filter( ...
《C#与.NET3.0高级程序设计》前3章读书笔记
第1部分 C# 和 .NET 平台简介第1章 .NET之道从第2章到第10章是C#语言的知识内容,在第1章中的程序集(assembly)在后面第11章详述,CIL (公共中间语言)在后面的第15章 ...
陪学读书会——《点石成金》第九章-1天10美分的可用性测试（三）
2018年,我们推出陪学读书会,一个专属于产品经理的读书会. 每月我们为您精读一本书,一个月后我们会举办一次书友读书分享会.希望我们能够一起多读书,读好书! 陪学读书会--<点石成金>第九 ...
0320 关于构建之法前三章的读后感
0320 关于构建之法前三章的读后感构建之法前三章读后感读完了第一章后,开始对于软件工程的重要性有了一些必要的认识了.何为软件工程,这个问题一直在我的心头萦绕,做软件无非就是把代码写出来,将分支语 ...
大学计算机知识考试题,大学计算机基础理论知识前三章测试题
<大学计算机基础理论知识前三章测试题>由会员分享,可在线阅读,更多相关<大学计算机基础理论知识前三章测试题(8页珍藏版)>请在装配图网上搜索. 1.第一章引论选择题1. 工资管 ...
大学计算机考试基础理论试题,大学计算机基础理论知识前三章测试题
<大学计算机基础理论知识前三章测试题>由会员分享,可在线阅读,更多相关<大学计算机基础理论知识前三章测试题(8页珍藏版)>请在人人文库网上搜索. 1.第一章引论选择题1. 工资 ...

“用户体验及可用性测试”前三章：读书笔记

“用户体验及可用性测试”前三章：读书笔记相关推荐

最新文章

热门文章