可用性測試報告怎麼寫提示詞（觀察記錄整理、問題嚴重度分級、證據與原話、改進建議與優先級）
做完可用性測試後整理報告時用：把多位參與者的觀察記錄、原話和任務數據整理成一份結論清楚的報告——問題按嚴重度分級、每個問題有證據（幾人遇到、原話、截圖位置）、改進建議有優先級，方便和設計、開發團隊討論。
通用大模型 對話模型通用
身份：資深用戶研究員。你寫報告的原則：每個結論都要能回溯到具體的觀察；報告是給團隊「做決定」用的，所以先寫最嚴重的問題。 測試概況（產品、版本、參與者人數與類型、測試日期）：[測試概況] 任務列表與成功標準：[任務列表] 每位參與者的記錄（任務完成情況、用時、關鍵行為、原話）： [觀察記錄] 團隊最關心的問題：[團隊關注] 請輸出報告： 1. 一頁摘要：測試目的、參與者、3 個最重要的發現、最需要優先處理的問題。 2. 任務數據表：任務 | 完成率 | 平均用時 | 平均易用性評分（如有）| 主要問題。 3. 問題清單，每個問題包含： - 問題描述（客觀描述用戶行為，而不是「用戶很笨」）； - 出現人數 / 總人數； - 嚴重程度：嚴重（阻止完成任務）/ 中等（明顯拖慢或導致錯誤）/ 輕微（有困惑但能完成）； - 證據：1–2 句參與者原話、對應的頁面或截圖位置； - 可能原因（推測要標註）； - 改進建議（可以給 1–2 個方向，不替設計師做最終方案）。 4. 做得好的地方：用戶順利完成、表達滿意的地方，避免改版時被誤傷。 5. 優先級矩陣：按「嚴重程度 × 影響用戶比例」排序，建議本次迭代必須修復、可以排期、觀察的問題。 6. 研究侷限：樣本量、參與者代表性、原型與真實產品的差異。 7. 後續建議：需要進一步驗證的問題和方法。 約束：原話不改動；參與者匿名（用 P1、P2 編號）；不把個別參與者的偏好當成普遍問題。
高亮處換成你自己的內容：[測試概況]、[任務列表]、[觀察記錄]、[團隊關注]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[觀察記錄] 可以是記錄員的筆記、錄屏轉寫的關鍵片段，按參與者分段粘貼即可，格式不統一也沒關係。[團隊關注] 寫出團隊最想知道的問題，報告會優先回答這些。
常見坑：
- 報告按參與者逐個複述，讀者要自己總結問題，很少有人能看完；
- 問題描述帶有主觀判斷（「這個設計很糟糕」），引發團隊防禦；要客觀描述行為和證據；
- 只寫問題不寫做得好的地方，下一版可能把有效的設計改掉。
迭代追問：「把一頁摘要改寫成在評審會上 5 分鐘講完的講稿」「為嚴重問題第 1 條寫 3 個設計改進方向」「把問題清單轉換成可以導入項目管理工具的任務」。
示例輸出
示例，僅供參考（虛構：生鮮 App 結算流程，6 位參與者）
| 任務 | 完成率 | 平均用時 | 主要問題 |
|---|---|---|---|
| 使用優惠券 | 3/6 | 2 分 40 秒 | 優惠券入口不明顯 |
問題 1（嚴重）：6 人中有 3 人沒能找到使用優惠券的位置，其中 2 人誤以為優惠券會自動抵扣。
- 證據：P2「我以為它會自動幫我用最划算的」；P5 在結算頁上下滑動 4 次後放棄。
- 可能原因：入口在「支付方式」下方，文字為灰色（推測）。
- 改進方向：在金額旁直接顯示「可用 1 張券」並提供一鍵使用。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～