可用性測試計劃提示詞（測試目標、任務場景、招募標準、主持人腳本、成功率 / 時長 / 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 條評論
還沒有評論，來搶沙發～