背景

• 评估总是需要的
• 什么是评估？
  系统化的数据搜集过程
  目的是了解用户或用户组在特定环境中，使用产品执行特定任务的情况
• 评估不是设计过程中一个单独的阶段
  优秀的交互设计师应掌握如何在不同的开发阶段评估不同的系统

评估目标和原则

评估目标

评估的优点

• 能够在交付产品之前（而不是之后）修复错误
• 设计小组能够专注于真实问题，而不是假想问题
• 工程师们能专心于编程而不是争论
• 能够大大缩短开发时间
• 销售部门可获得稳定的设计

评估的目标

• 评估系统功能的范围和可达性
• 评估交互中用户的体验
• 确定系统的某些特定问题

评估原则

• 评估应该依赖于产品的用户
  与专业技术人员的水平和技术无关
• 评估与设计应结合进行
  仅靠用户最后对产品的一两次评估，不能全面反映出软件可用性的
• 评估应在用户的实际工作任务和操作环境下进行
  根据用户完成任务的结果，进行客观的分析和评估
• 要选择有广泛代表性的用户
  参加测试的人必须具有代表性

评估范型和技术

“范型”与“技术”

• 范型与具体学科相关，对如何评估有很大影响
  可用性测试是一种评估范型
• 每种范型有特定的技术
  可用性测试的技术有观察、问卷调查、访谈等

评估范型

• 快速评估
• 可用性测试
• 实地研究
• 预测性评估

快速评估

• 设计人员非正式地向用户或顾问了解反馈信息，以证实设计构思是否符合用户需要
  可在任何阶段进行
  强调 “快速了解”，而非仔细记录研究发现，在设计初期了解用户对新产品的意见、在设计末期了解用户对图标设计的看法等
  得到的数据通常是非正式、叙述性的，可以口语、书面笔记、草图、场景的形式反馈到设计过程
  是设计网站时常用的方法
• 基本特征：快速

可用性测试

• 评测典型用户执行典型任务时的情况
  包括用户出错次数、完成任务的时间等
• 基本特征
  是在评估人员的密切控制之下实行的
• 主要任务
  量化表示用户的执行情况
• 缺点
  测试用户的数量通常较少
  不适合进行细致的统计分析

实地研究

• 基本特征
  在自然工作环境中进行
• 目的
  理解用户的实际工作情形以及技术对他们的影响
• 作用
  探索新技术的应用契机
  确定产品的需求
  促进技术的引入
  评估技术的应用
• 分类
  评测人员作为“局外人”
  评测人员也可作为“局内人”或测试用户

预测性评估

• 专家们根据自己对典型用户的了解（通常使用启发式过程）预测可用性问题，也可使用理论模型
• 基本特征
  用户可以不在场
  使得整个过程快速、成本较低
• 启发式评估是典型的预测性评估方法
  注意：
  1）启发式原则应定制
  2）可能误导设计人员，且有些结果可能并不准确

评估范型比较

评估技术

• 观察用户
  有助于确定新产品的需求
  也可用于评估原型
  挑战：如何在不干扰用户的前提下观察用户，以及如何分析大量数据
• 询问用户意见
  简单，调查用户数量从几个到几百不等
• 询问专家意见
  “角色扮演”方式评估
  同时专家会提出解决方案
• 测试用户的执行情况
  可比较不同设计方案优劣
  通常在受控环境中进行
• 基于模型和理论，预测界面的有效性
  常用技术如GOMS模型和KLM模型等

评估范型和技术的关系

每种范型有特定的技术

评估方法的选择

区分评估技术的因素

• 评估在周期中的位置
  设计早期阶段的评估更快速、便宜
• 评估的形式
  实验室环境or工作环境
• 技术的主客观程度
  技术越主观，受评估人员知识的影响越大，如认知走查等
• 测量的类型
  与技术的主客观性有关
  1）主观技术：定性数据
  2）客观技术：定量数据
• 提供的信息
  低层信息：这个图标是可理解的吗？
  高层信息：这个系统是可用的吗？
• 响应的及时性
  边做边说法可及时记录用户行为
  任务后的走查取决于对事件的回忆
• 干扰程度
  直接响应测量可能会影响用户表现
• 所需资源
  设备、时间、资金、参与者、评估人员的专业技术及环境等

评估技术的分类

评估方法组合

• 评估方法的组合取决于项目待评估的具体特性
• 常用组合：（一个经验性评估+边做边说或其他形式的可用性测试）
  1）启发式评估+边做边说等用户测试技术
  专家可通过启发性评估排除显而易见的可用性问题
  重新设计后，经用户测试，反复检查设计的效果
  2）访谈+问卷调查
  先对小部分用户进行访谈，确定问卷中的具体问题
• 启发式评估vs.用户测试
  前者不需要用户参与
  二者发现的可用性问题不同，可以互补

评估步骤

DECIDE评估框架

• 确定（Determine）评估需要完成的总体目标
• 发掘（Explorer）需要回答的具体问题
• 选择（Choose）用于回答具体问题的评估范型和技术
• 标识（Identify）必须解决的实际问题，如测试用户的选择
• 决定（Decide）如何处理有关道德的问题
• 评估（Evaluate）解释并表示数据

确定目标

• 评估目标决定了评估过程，影响评估范型的选择
• 为什么要评估？
  产品设计是否理解了用户需要？
  最终界面是否满足一致性要求？
  调查技术的引入对用户工作的影响？
  探讨新产品应做的改进？
• 举例
  1）设计界面时，需量化评价界面质量
  适合进行可用性测试
  2）为儿童设计新产品时，要使产品吸引人
  适合采用实地研究技术，观察儿童交谈

发掘问题

• 根据目标确定问题
  目标：找出为什么客户愿意通过柜台购买纸质机票，而非通过互联网购买电子机票
  问题：
  用户对新票据的态度如何？是否担心电子机票不能登机
  用户是否能够通过互联网订票？
  是否担心交易的安全性？
  订票系统的界面是否友好？是否便于完成购票过程？
• 问题可逐层分解

选择评估范型和技术

• 范型决定了技术类型
• 必须权衡实际问题和道德问题
  最适合的技术可能成本过高
  或所需时间过长
  或不具备必要设备和技能
• 可结合使用多种技术
  不同技术有助于了解设计的不同方面
  不同类型数据可从不同角度看待问题
  组合有助于全面了解设计的情况

明确实际问题

• 用户
  应选择恰当的用户参与评估
  1）能代表产品的目标用户群体
  2）可以先做测试，确定用户技能所属的用户群
  任务时间多长，20分钟休息一次
  可在任务执行前，安排用户熟悉系统
• 设施及设备
  如需多少台摄像机录像，具体摆放在何位置
• 期限及预算是否允许
• 是否需要专门技能，没有可用性专家

处理道德问题

• 应保护个人隐私
  除非获得批准，否则书面报告不应提及个人姓名，或把姓名与搜集到的数据相联系
  受保护的个人资料包括健康状况、雇佣情况、教育、居所和财务状况等
  可在评估前签署一份协议书
• 指导原则
  说明研究的目的及要求参与者做的工作
  说明保密事项，对用户&对项目
  测试对象是软件，而非个人
  对测试过程的特殊要求，是否边做边说等
  用户可自由表达对产品的意见
  说明是否对过程进行录像，不能拍摄用户的面部
  欢迎用户提问
  用户有随时终止测试的权利
  对用户话语的使用应征得同意，并选择匿名方式
  己所不欲，勿施于人

解释并表示数据

• 搜集什么类型的数据，如何分析，如何表示？——通常由评估技术决定
• 可靠性
  给定相同时间，不同时间应用同一技术能否得到相同结果
  非正式访谈的可靠性较低
• 有效性
  能否得到想要的测量数据
• 偏见
  评估人员可能有选择地搜集自己认为重要的数据
• 范围
  研究发现是否具有普遍性
• 环境影响
  霍索恩效应

小规模试验

• 对评估计划进行小范围测试
  以确保评估计划的可行性
  如检查设备及使用说明
  练习访谈技巧
  检查问卷中的问题是否明确
• 小规模试验可进行多次
  类似迭代设计
  测试——反馈——修改——再测试
  快速、成本低

可用性问题分级

• 评估结果总是可用性问题清单，以及改进建议
• 方法一：基于量化数据的分级
  如多少人遇到该问题，耗费多少时间等
• 方法二：问题严重性的主观打分，取平均值
  0：不是一个可用性问题
  1：一个表面的可用性问题
  如果项目时间不允许，可不予纠正
  2：轻微的可用性问题
  优先级较低
  3：重要可用性问题
  需要重视，给以高优先级
  4：可用性灾难
  产品发布之前必须纠正
• 方法三：可用性分级的两个因素
  多少用户会遇到这个问题
  用户受该问题影响的程度
  
• 方法四：该问题只在第一次使用时出现，还是会永远出现
  举例：菜单条中的下拉菜单
  用户从不尝试下拉用图标表示的菜单
  有人告诉他们后，可马上知道如何克服该不一致性问题
  因此该问题不属于永久性的可用性问题

评估

评估之观察用户

• 直接观察
  实验室观察
  现场观察
• 间接观察
  日志和交互记录
• 数据记录
  纸笔
  音视频
  日志和交互记录
• 数据分析
  定性分析
  定量分析

评估之询问用户和专家

• 访谈
  问卷调查
  和访谈的区别
  选用
• 认知走查
  哪些特点
• 启发式评估
  灵活运用

评估之用户测试

• 用户测试的适用范围
• 用户测试步骤
  各步骤文档的包含内容
• 进行简单的数据分析
• 设计和组织一个用户测试