本周要回答： 当使用者不理解你的实现，也没有你在旁边提示时，工具仍能完成任务吗？
进入本周前： 至少一个项目能够运行、停止与恢复，具备合成演示数据和清楚的数据说明。
- 01取得同意
- 02观察任务
- 03修复一个障碍
- 04清楚交接
学习内容与理解目标
个人 FDE 的下一步不是扩大用户数量，而是验证自己的理解是否能够被别人使用。邀请一位知情同意的人，在合成数据上完成一个真实形式的任务；对方可以随时停止，不必提供私人资料。无法邀请时，用自己隔几天再做一个陌生任务作为弱化替代，并诚实说明没有外部用户验证。
观察行为比询问喜好更有用：哪里停住、哪句话理解错、哪里不敢点、遇到错误会怎么办。不要为了让测试“成功”不断在旁边指路。交接需要上手、数据、费用、限制、停止和恢复，而不仅是产品介绍。方法参考 R75 · GOV.UK Service Manual：Moderated usability testing 与 R76 · GOV.UK Service Manual：Getting users’ consent for research。
学习链接与选读范围
| 级别 | 官方或原始资料 | 本周只读这些 | 阅读预算 |
|---|---|---|---|
| 必读 | R75 · GOV.UK Service Manual：Moderated usability testing | 任务设计、主持方式与观察。 | 40 分钟 |
| 必读 | R76 · GOV.UK Service Manual：Getting users’ consent for research | 参与目的、记录内容、退出与同意。 | 30 分钟 |
| 选读 | R08 · MIT Missing Semester：Beyond the Code | 维护、协作与交接相关材料。 | 35 分钟 |
实战拆解
写一段易懂邀请：测试目的、预计占用、仅使用合成数据、是否记录、如何退出。未经额外同意不录音、不录屏、不收集账号或联系信息。
准备一个任务而不是操作指南，例如“安排三项活动并导出检查”。提供必要目标，不告诉每个按钮在哪里，让界面自己承担解释责任。
记录观察而非评价：停顿、误操作、问题、能否恢复。避免“用户不懂技术”这种没有改进指向的结论。
只修复一个影响最大的障碍，再让对方或一个新的合成任务验证。没有必要从一位用户的偏好推断所有人的需求。
写一页交接说明，包含运行、数据去向、费用、限制、导出清除、停止恢复与版本。公开反馈仅保留经同意的匿名概要。
交付与验收
| 本周交付 | 怎样确认真的完成 |
|---|---|
| 知情同意与观察方案 | 明确记录范围和退出方式；不要求真实私人资料。 |
| 真实反馈或替代说明 | 区分外部观察与自测，不伪造用户评价。 |
| 一页交接说明 | 陌生使用者能知道如何开始、停止和处理错误。 |
不用代码生成器的练习： 独立重写一条被用户误解的提示，并用新情景验证；不要只把文字变得更长。
隐私与安全检查： 去掉姓名并不一定匿名，职业、时间、任务和截图仍可能识别个人。公开报告优先使用合成重现，不上传访谈原文、音视频或私人日志。工作场景试用需另走组织批准流程。
落到日常生活： 观察工具是否减少解释负担。未来的自己也是“第二位用户”：一段时间后仍能理解、修复和停用，才是真的可维护。
过关或补课判断： 至少一个高价值问题被观察并改善，交接说明可用，就达成目标。没有受试者时保留限制，不强求招募。
本周可复制的协作提示
请帮我设计一个只用合成数据的单任务可用性观察，写明同意、记录与退出。优先观察而非引导，只改最重要的一个障碍，并制作上手、数据和停止恢复说明。不生成虚构用户反馈。
本周来源与核对范围
来源编号与核对说明沿用课程原文，基线为 2026-09-27。未逐一登录完成外部实验；实施前请核对最新版本与访问条件。
- R08MIT Missing Semester：Beyond the Code ↗
2026 讲义；作为维护与交接的补充阅读。
- R75
- R76GOV.UK Service Manual：Getting users’ consent for research ↗
用于知情同意的基本问题清单，不替代当地法律意见。