用戶故事地圖怎麼畫提示詞（用戶活動骨架、任務、細節，劃出行走骨架與 MVP 版本切片）
規劃新產品或一個大功能、團隊對「先做什麼」爭論不休時用：按用戶故事地圖（User Story Mapping）方法，把用戶完成目標的全過程排成橫向的活動骨架，往下展開任務和細節，再橫向切出 MVP 和後續版本，讓整個團隊看到全貌和取捨。（單個需求拆成用戶故事與驗收標準，可用「需求拆解」提示詞。）
通用大模型 對話模型通用
你是一位熟悉用戶故事地圖方法的產品教練。你強調：地圖的橫軸是「用戶的時間順序」，不是「系統的功能模組」；切版本時要保證每個版本都能讓用戶走完一遍完整流程。 產品 / 功能：[產品或功能] 目標用戶（可以有多類）：[目標用戶] 用戶要達成的目標：[用戶目標] 已知的需求、想法、反饋（可以很雜亂）：[需求清單] 第一個版本的時間或資源限制：[版本限制] 請完成： 1. 用戶活動骨架（Backbone）：按時間順序列出用戶為達成目標要經歷的 5–8 個大活動（如「發現 → 註冊 → 設定 → 首次使用 → 日常使用 → 分享」）。 2. 用戶任務（Walking skeleton 的來源）：每個活動下展開 2–5 個具體任務，用「用戶 + 動詞」描述。 3. 細節與變體：每個任務下列出更細的故事、可選做法、邊界情況，按重要性從上到下排列。 4. 文字版地圖：用表格呈現，列 = 活動，行 = 任務與細節由上到下。 5. 版本切片： - 行走骨架 / MVP：每個活動下選最少的任務，保證用戶能端到端完成一次目標； - 第二版、第三版各增加什麼； - 說明每條切線背後的取捨理由和要驗證的假設。 6. 遺漏檢查：從不同用戶類型的角度檢查是否漏掉了關鍵步驟（如首次使用的引導、出錯後的恢復、離開後回來）。 7. 待討論問題：需要和團隊、用戶確認的假設清單。 約束：故事從用戶視角寫，不寫成技術任務；不確定的需求標註「待驗證」。
高亮處換成你自己的內容：[產品或功能]、[目標用戶]、[用戶目標]、[需求清單]、[版本限制]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[需求清單] 可以把需求池、會議記錄、用戶反饋一股腦貼進來，AI 會把它們歸位到地圖上的不同位置，同時會暴露出「沒人提但用戶一定會遇到」的空白。[版本限制] 例如「6 周、2 名開發」，會決定 MVP 切線畫在哪裏。
常見坑：
- 橫軸按功能模組排（「用戶中心」「訂單模組」），失去了用戶視角，切出來的 MVP 可能根本走不通；
- MVP 每個活動都做得很深，最後只做了前兩個活動，用戶無法完成目標；
- 地圖畫完就鎖進文檔，團隊沒有一起討論，失去了它最大的價值。
迭代追問：「把 MVP 切片中的每個任務寫成用戶故事和驗收標準」「從第二類用戶的視角檢查地圖有沒有遺漏」「為 MVP 設計 3 個需要驗證的關鍵假設和驗證方法」。
示例輸出
示例，僅供參考（虛構：社區二手物品交換小程式）
| 發現 | 發佈物品 | 瀏覽與聯絡 | 完成交換 | 評價 |
|---|---|---|---|---|
| 從鄰居群看到連結 | 拍照上載物品 | 按距離瀏覽 | 約定時間地點 | 給對方評價 |
| — | 填寫想換什麼 | 收藏感興趣的 | 確認已交換 | — |
| — | 選擇分類（第二版） | 站內私信（MVP 用複製聯絡方式代替） | 交換記錄（第二版） | 信用分（第三版） |
MVP 切線：用戶能發佈物品、按距離瀏覽、聯絡對方、確認交換——端到端走通一次。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～