產品設計方法

從想法到可執行方案的設計過程。

MVP 思維#

MVP（Minimum Viable Product）不是做一個爛產品，而是用最小的投入驗證最關鍵的假設。

什麼是 MVP？#

寶玉的定義：

MVP 是能讓你學到東西的最小產品版本。

MVP 的目的不是「上線一個產品」，而是「驗證一個假設」。

MVP 的常見誤區#

誤區	問題	正確理解
MVP = 半成品	用戶體驗差，無法驗證	MVP 要可用，只是功能少
MVP = 做最少的事	可能驗證不了核心假設	MVP 要能驗證最重要的問題
MVP 只做一次	一次不夠	持續迭代，多次 MVP

設計 MVP 的步驟#

1. 明確要驗證的假設
   └── 我們相信 X 會帶來 Y

2. 確定最小功能集
   └── 哪些功能是驗證假設必須的？

3. 設計驗證方式
   └── 怎麼知道假設對不對？

4. 設定成功標準
   └── 什麼結果說明假設成立？

5. 快速開發上線
   └── 時間盒，不追求完美

6. 收集數據和反饋
   └── 定量+定性

7. 決定下一步
   └── 繼續、調整、還是放棄？

在動手做之前，先問「這個 MVP 要驗證什麼？如果驗證成功/失敗，我們會怎麼做？」

產品規劃#

Roadmap 的制定#

寶玉對產品路線圖的建議：

短期（1-3個月）：
├── 具體的功能和任務
├── 有明確的負責人和時間
└── 承諾度高

中期（3-6個月）：
├── 大致的方向和主題
├── 有初步的資源估算
└── 可能根據情況調整

長期（6-12個月）：
├── 戰略願景
├── 主要里程碑
└── 高度不確定

Roadmap 的溝通#

對象	關注點	溝通重點
高層	戰略對齊、資源投入	大方向、關鍵里程碑
團隊	具體工作、優先級	近期計劃、技術考量
銷售/客服	何時有什麼功能	對外承諾的節點
用戶	產品會變成什麼樣	願景和即將推出的亮點

需求優先級#

需求永遠做不完，如何決定先做什麼？

常用的優先級框架：

RICE 評分：

R - Reach（觸達）：影響多少用戶？
I - Impact（影響）：對每個用戶的影響有多大？
C - Confidence（信心）：我們對以上估算有多確定？
E - Effort（投入）：需要多少開發資源？

RICE Score = (R × I × C) / E

價值-成本矩陣：

       │ 高價值 │ 低價值 │
───────┼────────┼────────┤
低成本 │  優先   │  可選  │
───────┼────────┼────────┤
高成本 │  評估   │  不做  │

過度依賴框架，忽略了定性判斷。框架是工具，不是答案。最終還是需要人的判斷。

功能設計#

設計思維的過程#

邱岳描述的設計過程：

發散：
├── 這個問題可能的解法有哪些？
├── 競品怎麼做的？
├── 其他行業怎麼解決類似問題？
└── 有沒有創新的方式？

收斂：
├── 哪些方案可行？
├── 哪個方案最適合我們的情況？
├── 成本和效果的平衡？
└── 風險是什麼？

迭代：
├── 先做簡單版本驗證
├── 收集反饋
├── 持續優化
└── 知道何時停止

功能設計的要點#

完整性：

正常流程怎麼走
異常情況怎麼處理
邊界條件是什麼
用戶可能的誤操作

一致性：

與現有產品的一致
交互模式的一致
視覺風格的一致
用語的一致

簡潔性：

能少則少
默認值合理
減少用戶決策負擔

PRD 文檔結構#

1. 背景和目標
   ├── 為什麼要做這個功能
   ├── 要解決什麼問題
   └── 成功指標是什麼

2. 用戶故事
   ├── 作為 [用戶類型]
   ├── 我想要 [做什麼]
   └── 以便 [達成什麼目的]

3. 功能描述
   ├── 功能清單
   ├── 頁面流程
   ├── 交互說明
   └── 邊界和異常

4. 設計說明
   ├── 設計稿鏈接
   ├── 關鍵交互說明
   └── 適配要求

5. 技術說明
   ├── 技術約束
   ├── 介面需求
   └── 數據需求

6. 上線計劃
   ├── 灰度策略
   ├── 數據埋點
   └── 監控報警

產品設計原則#

用戶體驗設計原則#

邱岳整理的設計原則：

原則	說明	例子
可見性	用戶能看到可以做什麼	按鈕看起來像按鈕
反饋	每個操作都有響應	點擊後有 loading 或動畫
約束	限制錯誤操作的可能	不合法的選項灰掉
一致性	相同的東西表現一致	所有頁面的返回按鈕在同一位置
容錯	允許撤銷，減少錯誤代價	刪除有確認，刪除後可恢復

避免暗黑模式#

「暗黑模式」（Dark Pattern）是指利用設計誤導用戶的做法。這是不道德的，長期也會損害品牌。

常見的暗黑模式：

默認勾選用戶不想要的選項
取消訂閱流程故意複雜
誤導性的按鈕設計
隱藏重要資訊

問自己「如果用戶完全理解了這個設計的意圖，他會高興嗎？」如果答案是否定的，重新設計。

設計評審#

為什麼需要設計評審？#

發現設計中的問題
對齊各方理解
收集多元視角
記錄決策過程

設計評審的流程#

1. 準備
   ├── 準備設計稿和說明文檔
   ├── 明確要討論的問題
   └── 提前發給參與者

2. 評審會
   ├── 介紹背景和目標
   ├── 展示設計方案
   ├── 收集反饋和問題
   └── 討論替代方案

3. 跟進
   ├── 整理會議記錄
   ├── 確定修改項
   ├── 更新設計
   └── 必要時再次評審

如何給出好的設計反饋#

好的反饋：

指出具體問題
解釋為什麼是問題
提供改進建議
區分「必須改」和「建議改」

不好的反饋：

「我覺得不好」（太模糊）
「我喜歡 A 方案」（只是偏好）
在細節上糾纏太久
否定但不提建議

本章要點#

MVP 驗證假設：用最小投入驗證最關鍵問題
Roadmap 分層：短期具體、中期方向、長期願景
優先級框架：RICE、價值-成本矩陣等工具輔助決策
功能設計要完整：正常流程、異常處理、邊界條件
用戶體驗原則：可見、反饋、一致、容錯
設計評審：發現問題、對齊理解、收集反饋