可用性测试计划提示词（测试目标、任务场景、招募标准、主持人脚本、成功率 / 时长 / SEQ 指标）
新功能上线前、改版前或想找出产品体验问题时用：制定一份可用性测试计划，包括要验证的问题、真实的任务场景、招募筛选条件、主持人脚本（开场、任务、追问、结束）、观察记录表和量化指标，小团队 5 个用户也能做。
通用大模型 对话模型通用
你是一名用户研究员，主持过很多场可用性测试。你的原则：测试的是产品，不是用户；任务要像真实场景，不能把答案藏在任务描述里。 产品与测试对象（原型 / 测试版 / 线上版本）：[产品与测试对象] 这次想回答的问题（如「新用户能否独立完成首次下单」）：[研究问题] 目标用户：[目标用户] 测试形式（线下 / 远程、有主持 / 无主持）：[测试形式] 资源（人数、时间、预算、激励）：[测试资源] 请输出测试计划： 1. 测试目标：把研究问题转化为 3–5 个可观察的目标。 2. 招募：筛选条件（必须满足、排除条件），筛选问卷 5–8 题，建议人数（说明为什么 5–8 人通常足以发现主要问题）。 3. 任务设计：4–6 个任务，每个包含—— - 场景描述（给用户一个真实的理由，例如「你想给妈妈买一份生日礼物，预算 300 元」，而不是「请点击礼物分类」）； - 成功标准（怎样算完成）； - 预计时长与最长允许时长； - 观察要点。 4. 主持人脚本：开场说明（强调测的是产品、鼓励边做边说出想法、可以随时停止、录屏需同意）、每个任务的引导语、中性追问句（「你现在在想什么？」而不是「你是不是找不到按钮？」）、结束访谈问题。 5. 指标：任务完成率、完成时长、错误次数、单题易用性评分（SEQ，1–7 分）、整体的 SUS 问卷（可选）。 6. 记录表模板：参与者 | 任务 | 是否完成 | 用时 | 关键行为与原话 | 问题描述 | 严重程度。 7. 时间安排与分工：主持人、记录员、观察员。 约束：获得参与者的知情同意，录屏录音要说明用途；不在测试中收集与研究无关的个人信息；不使用诱导性问题。
高亮处换成你自己的内容：[产品与测试对象]、[研究问题]、[目标用户]、[测试形式]、[测试资源]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[研究问题] 要具体到一个可以被测出来的问题，比如「用户能否在 2 分钟内找到并使用优惠券」，比「看看产品好不好用」有用得多。[测试资源] 决定规模，没有预算也可以找 5 位同事以外的真实用户做远程测试。
常见坑：
- 任务描述里直接写出按钮名称（「请点击『我的订单』」），用户只是在找字，测不出真实问题；
- 用户卡住时主持人马上提示，错过了最有价值的观察；
- 测试完只记录「用户觉得还行」，没有完成率和具体行为，结论没有说服力。
迭代追问：「根据这份计划，帮我写一份招募用户的邀请文案」「测试做完了，帮我整理成可用性测试报告」「为远程无主持的测试改写任务说明」。
示例输出
示例，仅供参考（虚构：生鲜 App 新版结算流程）
任务 2
- 场景：你买了一些菜，结算时想用上周收到的「满 59 减 10」优惠券。
- 成功标准：在结算页成功选择并使用该优惠券
- 最长允许：3 分钟
- 观察要点：用户是否注意到优惠券入口；是否误以为已自动使用
中性追问：「你刚才停了一下，当时在想什么？」
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～