AI 原型可用性测试，要观察目标用户能否独立完成任务，而不只问“页面好不好看”。先连通关键页面，给参与者一个不带操作提示的任务，再记录路径、误解、求助和最终结果。原型链接坏了与用户看不懂入口要分开记录；否则团队很容易把制作故障当成设计问题。
本文适合产品经理、UX设计师和需要快速验证方案的创业团队。原型刚完成首轮生成时，可先按AI原型五轮迭代方法校准任务、结构与状态；当核心路径已经能点击，再用本文的方法判断它是否真的可用。
先定义这次AI原型可用性测试要验证什么
测试目标应写成可观察的问题，例如“新用户能否在3分钟内完成退款申请，并知道提交后的处理状态”。不要写“验证页面体验”“看看是否符合预期”，这类目标无法决定任务、记录项和通过条件。
每轮测试只选一到三个高风险任务。优先验证使用频率高、业务后果重、团队争议大或AI容易自行补全的部分。若页面和规则仍来自分散需求，可以先对照PRD转可评审原型的方法确认角色、页面、流程和状态来源，再开始招募参与者。
| 模糊目标 | 可测试目标 | 需要记录 |
|---|---|---|
| 看看筛选好不好用 | 采购专员能否找到本月5万元以上的待审批申请 | 入口、筛选条件、完成时间、错误 |
| 验证错误提示 | 附件上传失败后，用户能否保留表单并重新提交 | 是否理解原因、是否找到恢复动作 |
| 确认信息清晰 | 审批人能否判断金额来源并做出同意或驳回决定 | 阅读顺序、疑问、缺失字段 |
把AI初稿整理成可测试原型
可测试不等于高保真，但必须能完成目标任务。入口、关键页面、按钮反馈、成功结果和至少一种失败恢复路径要连通；演示数据应接近真实长度；尚未确认的规则必须标明为假设，不能让主持人临场解释。
可以用AI生成可编辑原型搭出核心路径，再手动检查跳转、字段和状态。测试前由不参与设计的人走一遍，排除链接断开、页面打不开、明显占位文本等“原型故障”，避免把制作问题误判为用户问题。
- 只保留本轮任务需要的页面，隐藏未完成入口。
- 准备固定起始页和可重复的初始数据。
- 正常、空、错、加载、无权限等状态只展示与任务有关的部分。
- 为主持人准备重置方式，保证每位参与者从相同条件开始。
任务脚本怎么写才不会提示答案
好的任务脚本包含背景、目标和完成信号，但不直接说按钮名称、页面位置或操作顺序。例如不要写“点击右上角筛选，选择金额大于5万”，应写“你需要找出本月金额超过5万元、仍待你处理的申请，并打开其中最早提交的一笔”。
示例任务：你是采购专员，刚收到一笔办公设备申请。请找到本月金额超过5万元、仍待你审批的申请，查看预算与附件，选择合适处理结果，并确认系统已经记录你的决定。
脚本后面另写主持人检查项：起点在哪里、什么算完成、允许提供哪些中性提醒、何时终止。提醒只能复述目标，例如“请继续按你认为自然的方式操作”，不能说“那个入口在左侧”。
可直接使用的预约改期测试脚本
以下以预约服务为练习。目标用户是曾在线预约、但没见过这版原型的人；已确认规则为“至少提前 24 小时允许自助改期，每个预约最多改一次”。两项任务分别检查正常完成与受限后的理解，不要求参与者猜业务规则。
主持人开场：“今天想了解这个预约页面是否容易理解，我们测试的是页面，不是你的能力。请按平时使用手机的方式尝试，也可以说出正在想什么。找不到或看不懂都很有帮助；你随时可以暂停。过程中我通常不会告诉你具体点哪里，结束后再一起讨论。”
| 项目 | 任务 A：正常改期 | 任务 B：不可自助改期 |
|---|---|---|
| 参与者看到的任务 | 你预约了下周二 14:00 的服务，现在希望改到下周四 10:00。请试着完成调整，并告诉我最终预约是什么时间。 | 你发现明天上午的预约与临时行程冲突。请看看还能怎样处理，并说说你认为接下来会发生什么。 |
| 主持人准备 | 固定当前时间，保证距离预约大于 24 小时；目标时段有余量；未改过期 | 固定当前时间，使距离预约少于 24 小时；有联系客服入口但不承诺一定可改 |
| 完成信号 | 参与者自行提交，能从结果页准确说出新时间 | 能理解不能自助改期的原因，找到后续渠道，不误以为已改成功 |
| 不要说的提示 | “点右边的改期按钮”“往下滑就有” | “联系客服就行”“你看看灰色按钮” |
任务 B 不是失败任务：如果业务本来不允许自助改期，用户能够理解限制并找到正确下一步，就是这项任务需要验证的结果。不要把“完成预约修改”作为所有状态的统一成功标准。
任务应使用用户语言而非界面标签，避免提示正确路径。这与 NN/g 关于任务场景的建议一致。脚本里的完成信号交给主持人，不必照读给参与者。
参与者和场次应该怎么安排
参与者要符合目标角色，而不是随手找熟悉项目的同事代替。新用户任务要找没有使用经验的人；专业后台要确认参与者是否理解真实业务。小轮次的价值在于尽早发现主要障碍并继续迭代，不应把少量测试结果包装成全体用户的统计结论。
每场可安排一名主持人和一名记录者。主持人说明“我们测试的是原型，不是测试你”，提醒参与者边做边说；记录者只记录行为、原话和界面位置，不在现场讨论解决方案。涉及账号、客户数据或内部流程时，使用脱敏内容并说明录屏范围。
观察时记录行为，不要替用户解释
记录表应把事实与解释分开。事实是“参与者在列表顶部停留20秒，两次打开错误筛选项”；解释是“筛选入口不明显”。先保留事实和原话，测试后再由团队归因，能减少观察者把个人判断写成用户结论。
建议记录任务是否完成、完成路径、明显停顿、误点、返回、求助、对状态的理解和失败后的恢复方式。时间可以帮助比较同一任务的迭代版本，但不能脱离任务难度和参与者背景单独判断好坏。
把发现整理成可修改的问题清单
测试结束后，不要直接把所有评论变成修改需求。先合并同一根因，再用“问题发生在哪里、用户想完成什么、观察到什么、造成什么影响、建议验证什么”描述。优先级可综合任务是否中断、影响范围、业务风险和恢复难度。
| 等级 | 判断 | 处理方式 |
|---|---|---|
| P0 阻断 | 核心任务无法完成，且没有替代路径 | 修复后重新测试，不进入评审 |
| P1 严重 | 需要帮助才能完成，或可能造成高风险错误 | 本轮修复并验证关键路径 |
| P2 一般 | 任务可完成，但理解或操作成本明显偏高 | 纳入迭代并观察复现 |
| P3 优化 | 不影响结果的局部表达和视觉问题 | 结合规范统一处理 |
问题修复时可参考后台系统状态设计方法补齐空、错、加载、无权限与恢复动作；修改后必须用原任务复测，不能只看新页面是否更整齐。
一张观察表，把独立完成、辅助完成和故障分开
每位参与者、每项任务各占一行。先记原话和动作，再写解释；主持人一旦提供了具体操作帮助，就不能再记为“独立完成”。空表可直接复制：
| 任务 / 原型版本 | 行为与原话 | 主持人帮助 | 结果类型 | 问题与待验证原因 |
|---|---|---|---|---|
| ____ | ____ | 无 / 复述目标 / 具体提示：____ | 独立完成 / 辅助完成 / 未完成 / 原型故障中断 | ____ |
下面三行展示填法，不是用户研究统计数据。实际测试时应填写真实观察，不能直接当作测试结论。
| 观察到的过程 | 如何记录结果 | 接下来做什么 |
|---|---|---|
| 参与者反复打开预约详情，没有找到改期入口；主持人指向入口后完成 | 辅助完成；同时写下具体提示发生的位置 | 检查入口名称与层级，下一版用相同任务再测 |
| 参与者找到目标时段，但“确认”按钮的原型跳转断开 | 原型故障中断；不据此判断用户不懂操作 | 修复链接后重新走一遍；保留中断前观察 |
| 参与者读到 24 小时限制，找到联系客服，却说“应该已经替我改好了” | 未正确理解后续状态；不能因点到客服就记成功 | 核对按钮文案、反馈状态及客服承诺是否造成误解 |
计时也要标记中断：若主持人解释业务背景或原型卡住两分钟，就不要把这段时间直接当作操作耗时与下一版比较。小样本测试更适合发现和理解问题；若要对外报告完成率，应同时说明参与者范围、任务定义、分母和辅助规则。
从一个发现走到下一版，不急着投票改界面
假设观察是“找到了客服，但以为已经改期成功”。先分清原因：是用户没读文字，还是界面用了“已处理”的成功样式，或按钮名暗示能立即完成？对应修正可能完全不同。先保留原话、当时页面与行为，再讨论一个可验证的修改假设。
问题：联系客服后，被误认为已经完成改期。
证据：填写实际观察原话、页面版本与操作位置。
假设：结果页的成功样式掩盖了“等待客服确认”。
本轮修改：区分“已发起联系”和“改期成功”两种状态。
复测任务：沿用任务 B，不向参与者解释修改点。
检查信号：参与者能否说清当前预约尚未变更及下一步。AI原型可用性测试检查清单
- 测试目标是否能用用户行为和结果判断？
- 每个任务是否有真实场景、目标和完成信号？
- 脚本是否避免按钮名、位置和操作顺序提示？
- 参与者是否符合目标用户角色和经验？
- 原型是否能从固定起点走到成功或失败结果？
- 记录是否区分行为事实、用户原话和团队解释？
- 问题是否说明位置、证据、影响和优先级？
- 高优先级问题修复后是否用同一任务复测？
常见问题
AI生成原型做到什么程度才能测试？
核心任务能点击完成即可，不必等待全部视觉细节。关键是入口、主要信息、操作反馈和结果状态真实到足以触发用户判断。
可用性测试和原型评审有什么区别？
可用性测试观察目标用户能否完成任务；原型评审由产品、设计、研发和业务核对需求、规则与实现边界。前者提供用户行为证据，后者形成团队决策。测试发现进入评审时，可沿用产品原型评审流程明确责任人与处理结论。
主持人可以回答参与者的问题吗？
可以澄清测试背景和任务目标，但不应提示界面操作。若必须帮助才能继续，应记录帮助发生的位置和内容，因为这本身就是可用性问题证据。
AI能快速生成多个方案，但只有真实任务能告诉团队哪个方案更容易被用户理解和完成。把测试目标、脚本、观察证据和问题分级固定下来，每次生成与修改才会从主观讨论变成可复查的产品学习。
