重构的问题
如果只问： 怎样完成一次可用性测试？
进一步追问： 哪些设计假设需要在还能修改时检验？把测试放回开发过程，才有机会让发现影响下一版设计。
最初的需求
有些团队在产品接近定型时才来讨论可用性，希望招募用户、执行任务、得到一份测试报告。这时一旦发现问题，修改可能同时牵涉硬件、软件、说明材料和培训。
我认为需要先讨论的是：现在还有哪些设计假设没有验证，应该在哪个阶段发现它们？这个问题会改变测试的时间、任务和交付内容。
我的角色
我负责方向开拓、方法设计、方案与关键项目交付，也参与团队能力建设。工作包括把相关标准要求整理成项目步骤，设计研究任务与记录方式，协调企业、检测认证机构和研究团队。
这些项目通过 Noldus 开展。我也参与可用性工程软件的功能定义与方法输入；团队和产品的全部成果不等同于我个人完成。
我怎样推进
先把用户、环境、操作任务与可能的使用错误梳理出来，再确定当前评价需要回答什么。设计还可以调整时，重点是观察哪里让人困惑、误操作或需要协助，并把发现送回设计讨论。
执行前做预测试，检查设备、任务语言和环境会不会干扰观察。执行中保留视频时间戳，把动作、用户解释和研究者判断连接起来。整理结果时，分别说明观察到什么、可能的原因、需要进一步检查什么。
眼动或其他测量工具要能回答额外的问题才加入。它们不能代替任务设计和对具体错误的分析。
已经留下什么
相关工作覆盖呼吸机、监护、手术设备与 IVD 等产品，累计服务 25+ 家医疗器械企业及相关机构。项目经验进入研究方案、记录模板、培训与后续评价流程。我也整理标准和案例的内部检索索引，用于准备方案和查找出处。
这里能说明的是我的工作范围和交付方式。具体项目结果、设备细节、原始记录与监管文件受保密约束；本文不将服务数量作为产品安全或注册结果的证明。
验证进入设计的时机
- 洞察明确要检查的假设
- 设计 ⇄ 观察反馈回到仍可修改的设计
- 确认再检查是否回答了问题
洞察 → 设计与观察反复迭代 → 确认方法示意
