试玩测试：观察，而不是教玩家
你在旁边说“点蓝色，再点右边这个”，玩家顺利完成了消除，但你还不知道他自己能否理解。试玩时最难的动作，常常是忍住不教。
一轮只围绕几个关键问题
本轮可以只问：第一次来的玩家能否找到目标、完成一次蓝色消除，并在失败后知道怎么重试？如果把所有关卡、商业化和回访一起测，记录和解释都会变困难。
参与者应接近目标情境，并且对本作不熟悉。开发者朋友可以帮忙找程序缺陷，但不能自动代表真实目标玩家。
一份可以照着执行的脚本
开场：我们在测试游戏，不是在考试。遇到不清楚的地方很有价值。
请按你平常的方式操作，可以说说你以为会发生什么。
如果录屏，先说明用途、保存方式并征得同意。
任务一：请开始一局，尝试完成屏幕上的目标。
任务二：现在这局结束了，请选择你希望继续的方式。
任务三：模拟离开一会儿，再回来接着玩。
结束后：你觉得这一局要做什么？刚才哪一步最不确定？
这些任务故意没有说出按钮名称和正确答案。你想观察玩家如何理解入口和结果，而不是测试能否照指令点击。
怎样记录才便于复盘
| 位置 | 观察到的行为或原话 | 暂定解释 | 后续核对 |
|---|---|---|---|
| 目标区 | 先点两对橙色，再看顶部 | 可能没理解只收集蓝色 | 询问对目标的理解 |
| 无效选择 | 反复点斜对角 | 可能不理解相邻 | 看是否出现纠错信息 |
| 失败结算 | 问“确定会去哪” | 文案没有表达目的地 | 改名后再次测试 |
上表为模拟记录示例，不是真实测试结果。正式记录要回到现场观察，避免把自己的解释写成玩家原话。
记录是否独立完成、是否求助、停顿点和关键事件即可。时间的起点、终点和中断处理要统一，不把加载耗时和理解耗时混在一起。
玩家卡住时怎么办
先给一点自然尝试的空间，再问“你现在在想什么”。如果完全无法继续，可以给予必要帮助，随后标明这段任务是在协助下完成，避免计为独立成功。
强行要求全程出声可能影响节奏；需要自然操作速度的任务，可以操作后回看询问。研究方法应该服务问题，而不是机械执行一套话术。
从问题清单到下一次改动
优先处理会阻断、丢进度、损资源或没有出口的问题。再处理反复出现的理解障碍，最后看局部一致性与视觉完善。优先级要结合影响范围和证据，不只是出现次数。
AI 可以怎样帮忙
下面是匿名试玩记录，请按问题归类。
每个结论引用具体记录编号，区分观察、解释与建议。
保留相互矛盾的证据，不把少量样本扩展成群体比例。
最后给出本轮可执行的三个改动和各自复测任务。
动手练习
使用试玩记录模板安排一次小范围观察。先做一场预演，确认原型可用、任务不泄露答案、记录能对应到事件。收集到明显卡点就开始修正，再继续下一轮。
观察真实或潜在用户尝试任务的方法，参见 GOV.UK 主持式易用性测试指南。本章小游戏脚本、任务和模拟记录为原创示例。