可用性测试与体验诊断

一位玩家反复失败，最后说“不好玩”。你应该改配色、降难度，还是加提示？如果不知道他失败前发生了什么，这句话几乎无法指导行动。

本篇帮助你把宽泛评价拆成可定位、可复测的问题。以下情境是虚构演示。

为什么先观察，再解释评价

玩家可能没理解目标，可能知道解法却误触，也可能正常完成后觉得缺少选择。这些结果都可能被说成“不好玩”，但对应的改法分别是表达、交互和挑战结构。

任务测试让玩家在具体材料中行动，因而能留下停顿、反复、求助和退出的位置。测试前固定版本、任务、观察项与结束条件；说明在测试产品而不是考他，避免玩家把困惑隐藏起来。

给任务“请尝试完成一关”，不要先说“按这里拖到那里”，否则你检查的是执行指令而非独立理解。必要帮助可以提供，但记录发生时刻，帮助后完成不能算独立成功。

从一个停顿，走到不同后续动作

设想玩家在起点旁连续点按。可以先观察有没有反馈，再在尝试后问“你认为刚才发生了什么”。若他想拖动却没有成功，检查命中区域；若他认为点一下自动连线，检查操作表达；若他在构思路线，就不应立即弹出教学打断思考。

因此问题单保留证据编号、位置、候选解释、影响和复测任务。建议只是当前候选，不应覆盖原始记录。

观察到的影响	为什么优先级不同	后续方向
无法进入、完成不结算、丢进度	核心承诺已无法兑现	发布前处理阻断并复现恢复
经常不理解规则或误操作	大量尝试被无意障碍消耗	当前迭代重点检查表达与交互
局部提示不清，但可恢复	影响有限，还需比较范围	按频率、持续性和恢复成本排期
更喜欢另一配色	尚未显示任务受阻	结合目标人群与可读性判断

低频不等于轻微：一次权益丢失可能比多次偏好分歧更严重。频率、后果、可恢复性和持续性应一起看。

为什么挑战与操作困难不能一起消掉

解谜需要思考，而按钮能否点击不该成为谜题。若玩家理解目标、正常操作、愿意试不同策略，失败可能正是挑战的一部分；如果他不知道游戏有没有接受动作，失败就未必提供有意义的学习。

NN/g 的可用性原则可以帮助检查状态、语言、控制与恢复，不能代替目标玩家观察。把具体原则用于游戏时，仍要尊重有意的探索与挑战。关卡推理、尝试和提示的判断见 关卡设计。

为什么复测要考虑玩家已学会

同一玩家第二次完成，可能因为记住路线，而不是你的改动更清楚。用新玩家检查首次理解，用原玩家检查状态恢复是否符合预期；比较时保留经验和材料版本。

一次修改多个部分，即使结果改善，也难判断是哪项起效。优先处理少数影响核心任务的问题，检查动作是否真的覆盖原障碍，再决定是否扩展。小轮测试用于发现和修复问题，不用固定人数保证“已无问题”。

适用边界：能用不等于值得回来

任务完成说明在测试条件下能操作，不自动证明自然渠道会开始、长期会回来或商业化成立。测试现场和主持人也可能使人更耐心。结合结束原因与后续自然行为，保留结论范围。

若证据不足以区分操作、乐趣或可靠性，记录尚不确定，并安排能区分的下一步，别急于套一个设计标签。

练习：用 访谈与任务测试表 把观察分成操作、乐趣、可靠性和未知。每类提出一个最便宜的补证动作，并写出什么表现会让你改变解释。