设计工作

用 AI 设计可用性测试

用 AI 设计可用性测试指南覆盖研究目标、中性任务、试跑、观察记录、严重度讨论和证据复核，强调合成参与者不能代替真实用户与真实环境测试。

预计阅读: 3 分钟
首次发布: 2026/07/10
最近更新: 2026/07/10

用 AI 设计可用性测试，适合把设计目标转成中性任务、观察点、主持提示和记录表。AI 可以模拟主持人问法供试跑，却不能扮演参与者产生有效测试结果，也不能仅凭截图判断用户是否能完成任务。

页面摘要

项目	说明
阅读时间	约 8 分钟
适合人群	用户研究员、产品设计师、产品经理、内容设计师和测试协作者
核心产出	研究目标、任务脚本、主持指南、观察表、问题证据和下一步
使用前提	有可操作原型或产品、明确用户任务和参与者授权
不适合	用 AI 模拟用户宣布测试通过，或把参与者偏好当作行为证据

适用边界

可用性测试观察特定参与者在特定任务和环境中的行为，不能自动推断总体比例或长期产品效果。原型保真度、设备、网络、辅助技术和测试主持都会影响观察，应在报告中说明。

测试材料	AI 可辅助	人负责
任务脚本	检查是否泄露答案、生成改写候选	确认任务真实和伦理边界
主持指南	准备中性追问与救援规则	现场判断、建立信任与停止测试
观察记录	按来源整理行为、原话和问题	回看录像、确认语境
结果报告	聚类问题、找反例和未知	严重度、设计决策和样本限制

七步测试流程

写任务与决策：说明要观察哪一段真实任务，以及结果将支持什么设计决定。
选择参与者与环境：匹配关键经历、设备和辅助技术；不让便利样本代替目标人群。
设计中性场景：给目标和必要背景，不写按钮名、正确步骤或期望答案。
定义观察与救援：记录行为、停顿、错误、恢复与原话；规定何时提示或停止。
试跑完整流程：检查原型断点、任务时长、录制授权和记录表能否区分事实与解释。
整理来源证据：参与者编号、任务、时间点和观察一一对应；AI 聚类后必须回看原始片段。
讨论严重度与行动：结合频率线索、任务阻断、恢复成本和业务风险，由团队决定修改与复测。

假设示例：寻找并清空筛选条件

以下任务与观察为教学合成材料，不是真实可用性测试或用户结果。

示例任务

场景：你打开一个项目列表，当前只显示部分项目。请确认页面为什么只显示这些内容，并让列表恢复为不受筛选条件限制的状态。

主持规则：不提“筛选”“清空”或控件位置；参与者停顿时只问“你现在在找什么”。

假设观察输入

[P01 T1 01:20] 查看页面标题和搜索框，没有注意到状态标签；随后打开筛选入口并清空。
[P02 T1 00:45] 直接看到已应用条件，但不确定“重置”是否会影响保存的视图，停止操作。

示例输出

观察	证据	解释假设	下一步
状态提示可能不够显著	P01 01:20	也可能与内容位置或设备有关	回看视线与滚动路径，不宣布普遍问题
“重置”后果不明确	P02 00:45	术语可能与保存视图混淆	核对产品规则，测试更明确文案
两人最终状态不同	P01 完成；P02 停止	样本不足以计算成功率	作为问题线索继续验证

这份输出不报告“完成率”，也不说明哪个设计一定更好；它把观察、解释和行动分开。

决策与复核表

检查项	复核问题	通过标准
任务	是否描述目标而非步骤？	不泄露控件名和答案
环境	原型、设备与权限是否接近任务？	限制被记录
观察	行为和研究者解释是否分开？	可定位到参与者与时间
严重度	是否考虑阻断、恢复与风险？	不只按出现次数机械排序
结论	是否说明样本和方法边界？	不生成总体比例或因果效果

常见错误

任务写成“点击右上角筛选并重置”，直接给出答案。
主持人看到停顿就解释，无法观察恢复方式。
让 AI 观看截图后生成参与者行为和成功率。
只记录是否完成，不记录错误、信心与恢复成本。
挑选支持设计方向的片段，忽略反例和原型限制。

常见问题

可以用 AI 参与者做可用性测试吗？

不能作为用户证据。合成角色可用于检查脚本和列候选风险，但无法替代真实感知、动机、辅助技术和环境。

测试必须使用高保真原型吗？

不必。保真度取决于研究问题，但必须说明哪些交互、内容和系统反馈尚未实现，以免误读结果。

如何给问题定严重度？

综合任务阻断、恢复难度、潜在后果、出现线索与目标人群影响，由团队讨论；不要只让 AI 按次数打分。

参与者说喜欢就代表设计可用吗？

不代表。偏好可以记录，但还要观察是否理解、完成和恢复，以及实际任务是否得到支持。

带走什么

可用性测试依靠真实任务、真实参与者与可定位观察。AI 能改进脚本和整理材料，但不能生成测试证据或替团队宣布通过。