什麼是 PRD

PRD（Product Requirements Document，產品需求文件）是一份用來定義產品或功能「為什麼做、為誰做、要解決什麼問題，以及要做到什麼程度」的核心文件。它將使用者需求、產品目標、功能需求、使用情境與成功指標整理成一致的產品方向，讓產品、設計、工程及其他相關團隊在開發前對產品範圍與預期結果建立共識。簡單說，就像學習煮飯看食譜一樣，PRD 就像一份食譜，會告訴你需要哪些食材、烹煮流程、烹煮技巧。

AI 時代下，PRD 文件還重要嗎？直接 Prototype 不就好了嗎？

去年，前 Google Gemini 產品負責人表示，團隊正在從需求定義（PRD）轉向原型設計，引發大量討論。

我的答案是：PRD 依然重要。原因如下：

1. 釐清想法與問題脈絡
   • 透過書寫，先把問題脈絡與產品設計意圖想清楚，再餵給 LLMs 可能是比較好的方式；畢竟只有自己知道想打造怎樣的產品、解決怎樣的問題。我認為 LLMs 可以幫助你快速執行、輔助你看見思考盲點，但這一切的前提，都是你得先清楚自己的意圖。
2. 紀錄決策取捨的過程
   • 在做產品時，常常會有不同決策，有時是加法，有時是減法。把每個決策當下的取捨與理由寫下來，之後回頭才追得回「當初為什麼這樣決定」，也可以審視這樣決策是否正確。
3. 預先思考每一個使用者流程的樣貌
   • 作為設計師，在寫 PRD 時我都會要求自己先預想所有可能發生的流程和 Edge Case。邊寫邊想像每個畫面會有什麼元素、每個 Flow 可能需要處理哪些問題。這個過程其實是兩個方向來回切換：從大的觀點檢視每個 User Flow 與畫面，也從每個單一畫面回頭去想是否符合大方向。就是這種來回切換，才能讓設計與解決的問題相輔相成。

產品 PRD 初稿

這裡的 PRD 由於需求是給自己使用的產品，所以快速寫下我對產品的想像和需求，不用 AI，盡量寫出我的意圖、需求、初步想法，之後會再用這份 PRD 與 AI 進行討論，產出可進入開發階段的 PRD。

以下是我思考這個產品 PRD 的架構

1. 為什麼要打造這個產品

   • 使用者是一個平常有在用呼吸放鬆 App 產品的人，但由於其他 App 涵蓋功能太多太廣，包含專注力、睡眠，因此使用者想自己打造一個單純專注於呼吸這件事情的 App，作為每天日常使用。

2. 使用者

   • 一個在軟體產業的 Product Designer，喜歡個人成長與探索，關注心靈健康。

3. 產品形式

   • iOS 優先，先以 iPhone 為設計目標，Duo 應該先不支援XD

4. 這個產品要幫助使用者達成的目標

   • 透過呼吸達到放鬆與平靜
   • 將呼吸這個原子習慣培養成長期習慣

5. 技術執行（初步想法，未來要和 AI 討論研究）

   • Supabase 的資料庫選擇：一方面看到很多 Vibe Coding 社群都在推薦使用 Supabase；之前工作時有稍微接觸到，但不確定是否適合作為我的產品需求？
   • 呼吸引導的音訊（人聲、背景音）在 iOS 上要怎麼處理？人聲或背景音需要版權嗎？

6. 使用者情境

   • 作為一個使用者，我希望在不同情境下，透過呼吸引導達成睡眠/專注/放鬆等需求，讓當下雜亂的思緒和情緒緩慢沉澱下來
   • 作為一個使用者，我希望我能看到每次呼吸放鬆的視覺化數據，透過視覺回饋與紀錄來激勵自己要持續不斷練習，以及量化自己給自己放鬆的時間，讓這個原子習慣成為一個長期的習慣。

7. 使用者流程

   1. 呼吸練習
      • 選擇呼吸模式 → 聆聽呼吸引導 → 設定放鬆時間 → 開始進行呼吸練習（操作可暫停／繼續／離開）→ 寫下呼吸完後的感受
   2. 查看呼吸放鬆紀錄
      • 視覺化呈現呼吸 Log → 點擊查看每一天 Log → 查看紀錄與感受
   3. 初步評估會有的 Edge Case
      • 練到一半，電話打進來或鬧鐘響了，怎麼辦？音訊被搶走後，引導要暫停還是繼續？
      • 練到一半，使用者切出去滑別的 App，音訊直接停止並且計時暫停嗎？
      • 練到一半直接把 App 滑掉關閉，這算不算一筆紀錄？
      • 練到一半遇到網路訊號不穩，這次的紀錄會遺失嗎？

8. 視覺化

   • 所有單一呼吸紀錄（Heatmap）
   • 總呼吸放鬆時間
   • 每週呼吸放鬆時間（Bar chart）
   • 連續 X 天進行呼吸放鬆

9. 確定先不做的功能

   • 第三方登入/註冊
   • On-boarding

   初期只有自己先單機使用，所以我想可以先不需要帳號辨識身分及 On-boarding。

10. Wireframe 草稿 + 設計方向視覺探索

    • 會在 Day 4 執行

11. 驗收標準

    • 驗收標準等功能細節定義完後再回來進行補充。

Day 4 內容預告

Day 4 會分享產品視覺設計方向以及我如何進行探索。明天見，Cheers🍻