Lec-5 评估技术-观察用户

背景

• 观察用户怎样工作，很重要
  • 用户口头描述可能不客观、不完整、不真实
  • 用户会忽略细节
• 观察用户是所有可用性方法中最简单的方法
• 观察用户适用于开发的任何阶段

观察方式

• 真实环境观察
  • 观察者可以是参与者
  • 重点是应用的上下文
• 受控环境观察
  • 观察者不能参与
  • 重点是研究用户执行任务的细节

二者差别不大（？）。两者经常互为补充、互相参考。

以下是具体的观察方法。

直接观察

实验室观察

在专门为可用性测试而安装配置的固定设备的环境下进行的观察。

布局

测试区、观察区

二者分开，防止互相干扰。

还可以让用户坐在家里测试。

优缺点

• 优点：提供了可控且一致的评估环境

• 缺点：

  • 人为环境，不自然。可能降低测试结论的一般性。
  • 不利于观察多人之间的协作

实际问题

• 地点选择
• 设备安装
  • 录面部表情
  • 录交互过程
  • 录肢体语言
• 测试设备
• 文档准备
  • 协议书：说明测试目的、时间、用户权利等细节
  • 脚本：用户要执行什么任务

现场观察

在用户的实际环境中观察用户在使用软件时的情况。

是发现同使用环境有关的问题的最佳手段

问题清单

• 明确初步的研究目标和问题
• 选择一个框架指导观察
• 决定数据记录方式
  • 笔记、录音、摄像，还是三者结合
  • 确保设备到位并能正常工作
• 评估后，尽快与观察者或被观察者共同检查所记录的笔记和其他数据
  • 研究细节，找出含糊之处
  • 人的记忆能力是有限的，最好24小时内回顾数据
• 数据记录时，应区分个人意见和观察数据
  • 明确标注需要进一步了解的事项
• 培养良好的合作关系
  • 取得被观察对象的认可和信任
  • 避免只关注某些人，应注意小组的所有成员
• 处理敏感问题
  • 避免让观察对象产生被冒犯的感觉
• 注重团队协作
  • 通过比较不同评估人员的记录，得到更为可信的数据
• 应从不同的角度进行观察，避免只专注于某些特定行为

注意事项

• 观察人员自始至终应尽量保持安静
  1. 让用户感觉不到观察人员的存在
  2. 保证用户操作和平时工作的状态一样
• 当用户的操作令观察人员无法理解时
  1. 需要打断用户，请他对所做的某些操作进行解释
  2. 或把用户莫名其妙的操作行为记录下来
• 观察初期，应该拒绝用户的任何帮助请求
  1. 希望观察用户在没有系统专家指点的情况下如何操作
  2. 待评估完成后为用户提供适当帮助

间接观察

日志和交互记录

适用场合

1. 直接观察可能影响用户
2. 或者评估人员无法在现场进行研究
3. 可根据搜集到的数据，推断实际情形，并找出可用性和用户体验方面的问题

优点

1. 体现了用户是如何完成真实任务的
2. 使得从工作在不同环境下的大量用户那里自动收集数据变得相当容易
   1. 适用于用户分散、无法当面测试的情形
   2. 如互联网应用和网站设计项目等

观察框架

用于组织观察活动和明确观察重点。因为观察过程中发生的事件都非常复杂且变化迅速。

Goetz and Lecomfte框架

关注事件的上下文、涉及的人员和技术

Robson 框架

有助于组织观察和数据搜集活动

观察中的问题

• 不知道用户在想什么
  • 只能根据观察结果揣测

解决方法：边做边说

• 要求被测试人说出自己的想法以及想要做的事情
• 帮助观察人员了解他们的思考过程
• 当用户沉默时，观察人员可以提醒用户
• 优点：简单、只需要很少的专业技术
• 缺点：不自然，可能改变人们执行任务的方式

观察与访谈结合

• 观察方法只能展示用户做了什么，而无法知道用户为什么这样做
• 结合访谈
• 让用户面对记录数据时应非常小心，避免让用户产生被监视的想法