Lec 17用户测试
Lec 17 用户测试
官方课件：User Testing。用户验证（User Testing）= 观察真实用户使用你的系统，发现设计问题并改进。目标不是证明你的设计正确，而是发现设计错误。
User Testing 的最重要输出：Design Revision。User testing 最终目标不是 报告，而是：设计迭代。设计是假设的，而用户验证是实际的。User testing 的目的不是测试软件系统，而是测试 系统 + 人类交互的正确性
TL;DR
- 用户测试的目标不是证明设计正确，而是观察真实用户如何理解、行动和失败，并把证据转化为具体的设计修订。
- 启发式评估检查通用可用性原则，认知走查检查新用户能否完成任务；两者成本低，但都不能替代对真实目标用户的观察。
- 问卷适合收集态度，A/B 测试适合比较预先定义的方案；指标优化不能回答产品方向是否正确，也可能牺牲长期信任与用户价值。
- Think Aloud、最小介入和知情同意让研究既能暴露心智模型问题，又保护参与者的尊严、隐私与退出权。
- 绿野仙踪原型能在昂贵能力实现前验证交互假设，但只能证明用户是否理解和需要它，不能证明真实系统的准确性、成本或可扩展性。
启发式评估
在正式找真实用户测试前，可以先用两种低成本方法检查界面：
- 启发式评估（Heuristic Evaluation）发现通用可用性问题
- 认知走查（Cognitive Walkthrough）验证用户能否完成具体任务
启发式评估由 Jakob Nielsen 在 1992 年提出。它让多名评估者依据一组可用性原则，独立检查界面是否存在违反原则的地方。
流程
- 召集约 3–5 名评估者。
- 每位评估者独立浏览、操作界面。
- 对照可用性启发式原则，记录问题、违反的原则和严重程度。
- 在所有人完成前，评估者之间不要讨论。
- 最后再汇总发现、合并重复问题并排序优先级。
“独立评估、最后沟通”很重要：如果一开始就讨论，后面的评估者容易被他人的判断锚定，降低发现不同问题的机会。
优点与局限
| 优点 | 局限 |
|---|---|
| 可用于纸面草图、线框图、高保真原型或成品。 | 可能遗漏真实用户才会遇到的问题。 |
| 快速、成本低，不必招募用户。 | 可能出现“假阳性”：评估者认为是问题，真实用户却并不受影响。 |
| 能在用户测试前先消除明显问题，使用户测试聚焦更深层的任务、需求与心智模型问题。 | 结果取决于评估者的经验和对目标用户的理解。 |
认知走查
认知走查不只是问“界面是否美观或符合规范”，而是模拟一个新用户完成具体任务时的思考过程。
它关注的问题是：用户在每一步是否知道要做什么、能否找到正确操作、能否理解系统反馈，以及能否意识到自己正在接近目标。
每一步都问四个问题：
- 知道自己现在需要做某件事 ：用户是否意识到下一步需要采取行动？
- 发现正确动作，并把它和目标联系起来： 正确的按钮、链接、菜单或输入框是否可见？ 用户是否知道它正是自己需要的？
- 从动作后的反馈判断自己做对了：系统是否提供清晰反馈，例如状态变化、确认消息、错误提示或结果更新？
- 理解自己朝更大目标取得了进展：用户是否知道当前步骤在整个任务中的意义，而不是在机械地点击？
流程
- 列出用户可能要完成的一组任务。
- 对每项任务，拆解为用户动作序列，以及每步预期的系统响应。
- 对每个动作逐一回答上述四个问题。
- 如果发现问题，先假设它已经被修复，再继续检查后续步骤
最后一点很关键：不要让一个早期问题阻止你发现后续问题。例如用户找不到“创建预约”按钮时，仍应假设按钮已变得清晰可见，然后继续检查用户在填写时间、确认预约、收到反馈等步骤是否还有困难。
两种方法的分工
| 方法 | 主要问题 | 最适合的阶段 |
|---|---|---|
| 启发式评估 | 是否违反通用可用性原则？ | 原型完成后、用户测试前 |
| 认知走查 | 新用户能否完成某个具体任务？ | 已有用户流程与任务设计时 |
| 用户测试 | 真实用户实际上会如何理解、行动与失败？ | 有可交互原型或产品后 |
启发式评估和认知走查都不能替代用户测试；它们的作用是先清除显而易见的问题，让真实用户测试的时间花在更有价值的发现上。
问卷调查
问卷调查主要用于衡量用户的偏好、态度、看法或自我报告的行为。
优点
- 制作成本相对较低。问卷可以纯文字呈现，也可以展示截图、线框图或界面原型。
- 能较快收集并分析大量回答。适合了解更大样本的总体倾向，例如“用户更偏好方案 A 还是方案 B”。
- 不一定需要向参与者支付报酬。相比一对一访谈或用户测试，参与门槛通常更低。
局限
- 用户所说“自己将会怎么做”，往往与实际行为存在差距。例如用户可能说“我会使用这个功能”，但真正使用时并不会主动打开它。
- 设计高质量问卷本身很困难。问题措辞、选项顺序、样本选择、引导性提问和回答尺度都会影响结果；不好的问卷容易得到看似精确、实际却有偏差的数据。
A/B 测试
A/B 测试用于比较两个设计方案。
基本方法
- 50% 的用户看到方案 A；
- 50% 的用户看到方案 B；
- 预先定义成功指标，例如注册率、点击率、停留时长、互动率或转化率；
- 比较两组用户在指标上的差异，判断哪个方案表现更好。
局限
它容易鼓励“爬山式优化”（hill-climbing）：不断做边际上的小改进，却掩盖了重新思考产品方向、用户任务或核心交互模式的机会。
换句话说，A/B 测试很擅长回答“按钮用 A 还是 B 更好”，却不擅长回答“我们是否应该设计一个完全不同的按钮，甚至不该让用户走到这一步”
一位设计师 Jamie Divine 选定了一种团队都喜欢的蓝色。但产品经理让用户测试另一种颜色，发现把工具栏涂得更偏绿色时，用户更愿意点击。
颜色选择看起来微不足道，但点击是 Google 收入的重要来源；任何能提高点击率的改变都意味着更多收入。Divine 的团队反对采用更绿的颜色，因此 Marissa Mayer 选择了双方颜色之间的一个中间色调。
这个决定很圆融，但本质上仍是依赖直觉，而不是研究。此后，她要求团队测试两种竞争蓝色之间的 41 种不同色阶，以找出消费者最偏好的颜色。
Doug Bowman（Google 首位视觉设计师）在 2009 年 3 月对此批评道：
是的，Google 的一个团队无法在两种蓝色之间做决定，因此正在测试两种蓝色之间的 41 种色调，以观察哪一种表现更好。
我最近还参与过一场争论：边框应该是 3、4 还是 5 像素宽，并且被要求证明我的选择。
我无法在这样的环境中工作。我已经厌倦了争论这些微不足道的设计决策。这个世界上还有更令人兴奋的设计问题值得解决。
启示
A/B 测试应服务于明确、重要的产品假设，而不是把所有设计决定都降格为点击率优化。
在做 A/B 测试前，先问：
- 这个指标真的代表用户价值吗？
- A 和 B 的差异是否足够重要？
- 是否存在更大的设计方向值得探索？
- 即使 B 的点击率更高，它会不会损害长期信任、理解或用户体验？
用户研究
用户研究通常被视为评估交互设计的“金标准”：不是让团队猜用户会怎么做，而是直接观察真实参与者如何理解、操作、困惑、失败和完成任务。
基本流程
- 邀请目标用户或与目标用户相近的参与者到实验室、办公室或线上测试环境。
- 让参与者使用你的设计。
- 可以给出明确任务，例如“请找到并预约下周二晚上的餐厅”；
- 也可以开放探索，例如“请像平时一样看看你会如何使用这个产品”。
- 观察参与者的全过程，而不只看最终是否成功。
- 要求参与者采用 think aloud（出声思考）。
- 记录行为、语言、停顿、错误、绕路、误解和提问。
- 测试结束后访谈、复盘并整理为设计修改项。
用户研究可以结合前面的所有方法：
- 用问卷了解偏好；
- 用访谈理解动机；
- 用 A/B 测试比较两个方案；
- 用启发式评估找明显问题；
- 用认知走查检查任务流程；
- 并且可以在纸面草图、线框图、高保真原型或成品上进行。
Think Aloud：让参与者说出思考过程
只观察点击往往不够。参与者应该尽量说出：
- “我现在在想什么”；
- “我想完成什么”；
- “我现在有什么疑问”；
- “我正在阅读屏幕上的哪些内容”。
例如：
我以为这里可以搜索。 我不确定这个按钮会不会直接提交。 我在找取消预约的地方。 我看到它说“已保存”，但不知道是不是已经发布了。
出声思考对参与者很不自然，他们常会逐渐沉默。主持人可以中性地提醒：
请继续说出你正在想什么。 你现在想做什么？ 你看到这个页面时有什么疑问？
注意：提醒对方说话，不等于提示正确操作。
主持人的原则：少帮助，重观察
主持人应尽量不解释界面、不纠正理解、不引导下一步。用户测试的目标是发现系统哪里让人卡住，而不是帮助用户顺利完成任务。
测试前应先约定介入规则：
- 参与者误解界面时：先观察，不立即解释；
- 参与者短暂犹豫时：鼓励其继续说出想法；
- 参与者完全无法继续、明显沮丧或任务已经无法推进时：再提供最小必要帮助；
- 每次介入都应记录，因为“需要主持人帮助才能完成”本身就是设计问题。
用户研究的伦理要求
用户研究可能让人感到压力、尴尬甚至痛苦。参与者可能会把困惑和错误理解为“自己能力不够”，也可能在使用产品时无意透露隐私信息。若研究者与参与者之间存在权力差异，例如教师与学生、经理与员工，参与本身还可能带有强迫性。
研究者有责任降低这些风险。
研究前
- 参与必须是自愿的，不应施压；
- 取得 知情同意（informed consent）：说明研究目的、过程、记录方式、数据用途与潜在风险；
- 明确说明参与者可在任何时间停止，不需要解释原因，也不会受到惩罚；
- 尊重参与者时间，并给予公平报酬；
- 避免招募与你存在直接权力关系、难以自由拒绝的人。
研究中
- 明确告诉参与者：我们测试的是系统，不是你。
- 不把失败归因于参与者；
- 注意疲劳、焦虑、尴尬或情绪压力；
- 不诱导参与者泄露不必要的私人信息；
- 只收集完成研究真正需要的数据。
研究后
- 进行 debrief（事后说明）：解释研究真正目的，回答参与者的问题；
- 尽可能匿名化数据；
- 将录屏、录音、访谈记录和个人资料保存在安全位置；
- 限制谁能够访问数据，并在不再需要时按计划删除。
用户研究的价值来自真实观察；它的前提是参与者的尊严、隐私和自主权始终优先于研究结果。
绿野仙踪法
绿野仙踪技术是一种原型测试方法：用户以为自己正在使用一个真正自动化的应用，但系统背后的一部分“智能”或后端逻辑，其实由研究者手动扮演。
名字来自《绿野仙踪》：表面上是强大的“魔法师”，实际上幕后有人操控。
例如，你想测试一个“AI 旅行规划助手”：
- 用户在前端输入：“帮我规划三天东京美食旅行”；
- 用户看到的是完整聊天界面、地图、行程卡片；
- 但后台不是 LLM 或推荐系统自动生成结果；
- 而是研究者根据预先准备的流程，手动选择下一屏、粘贴回复、展示推荐行程。
这样你可以先验证：用户是否需要这个功能、是否理解交互、是否信任结果、结果应该以什么形式呈现；而不必先花大量时间开发真正的 AI、后端或算法。
核心原则
前端界面通常需要做得足够真实，因为这是用户实际接触和评价的部分；后台可以由远程的“魔法师”代替。
但模拟的成本必须低于开发真实系统。否则直接实现可能更划算。
设计步骤
1. 画出场景与应用流程
先明确：
- 用户会做什么；
- 系统在每一步应该如何响应；
- 哪些分支需要处理；
- 哪些情况无法支持，应该怎样提示。
例如旅行助手：
用户输入目的地与天数
→ 系统询问预算和兴趣
→ 用户选择“美食 + 博物馆”
→ 系统生成行程草案
→ 用户要求修改第二天
→ 系统给出替代方案2. 制作界面骨架
搭建用户能看到、能点击、能输入的前端原型：
- 聊天框；
- 表单；
- 推荐卡片；
- 地图或列表；
- 加载状态；
- 错误提示或修改入口。
不必真的完成后端逻辑，但用户操作后的界面反馈应足够连贯。
3. 为“魔法师”预留控制入口
设计研究者如何在幕后输入结果，例如：
- 选择接下来显示哪个页面；
- 输入或粘贴聊天回复；
- 选择推荐结果；
- 标记用户进入了某个区域；
- 模拟语音识别的转写结果；
- 触发“系统已识别物体/完成分析”等状态。
这些入口称为 hooks。它们应尽可能与未来的真实计算机接口对应。
4. 确保未来能替换为真实系统
这是最容易被忽略的一点。不要让原型的逻辑只能依赖研究者的临场发挥。
例如，未来系统会调用：
generateItinerary(destination, dates, preferences)那么研究者在原型阶段也应根据这些输入变量选择或生成回应，而不是只凭“感觉”回复。
这样以后可用真实 LLM、搜索系统或推荐模型替换魔法师，而不用重做前端交互。
5. 先排练
在正式用户测试前，让同学扮演用户，自己或另一位同学扮演 wizard，检查：
- 研究者能否跟上用户节奏；
- 所有常见分支是否有准备；
- 响应是否足够快；
- 用户是否会察觉幕后是人；
- 出现意外输入时如何处理。
适合测试什么？
特别适合尚未实现、实现成本高、或 AI/语音/视觉能力仍不确定的功能：
- AI 助手与 Agent；
- 智能推荐；
- 语音交互；
- 图像识别；
- 自动摘要、翻译、写作建议；
- 智能家居或机器人交互。
它测试的是：
如果系统真的能做到这些，用户会不会理解、需要、信任并有效使用它？
它不能证明：
真实系统是否能以足够准确、快速、便宜和可扩展的方式做到这些。
从测试证据到设计修订
测试记录只有在连接到“观察 → 解释 → 修改 → 再验证”时才成为设计证据。不要把参与者的单句话直接当需求，也不要只统计任务是否完成；应把停顿、误解、绕路和主持人介入与任务目标对照，提出能被下一轮测试证伪的修订假设。
我的理解
不同研究方法回答的是不同问题：问卷告诉你人们如何描述自己，日志与 A/B 测试告诉你行为指标怎样变化，用户测试则揭示行为背后的理解过程。方法之间不能互相代替；真正可靠的判断来自把多种证据指向同一个设计问题，并保留与假设冲突的观察。