好的產品始於對用戶的深刻理解。
發現用戶需求#
用戶不會直接告訴你他們需要什麼，你需要觀察他們的行為，理解他們的問題，然後設計解決方案。
用戶說的 vs 用戶要的#
寶玉指出一個常見誤區：
用戶告訴你的不一定是他真正需要的。
經典例子：
用戶說：「我需要一匹更快的馬」
用戶要的：更快到達目的地
解決方案：汽車
用戶說：「我需要更大的冰箱」
用戶要的：食物保鮮更久
解決方案：更好的保鮮技術需求的三個層次#
| 層次 | 說明 | 例子 |
|---|---|---|
| 表面需求 | 用戶直接表達的 | 「我要更快的搜索」 |
| 真實需求 | 背後的問題 | 「我找不到想要的東西」 |
| 深層動機 | 根本原因 | 「我想節省時間」 |
多問「為什麼」。用戶說「我要 X 功能」，問「為什麼需要這個？」「沒有它你會怎麼辦？」
用戶研究方法#
定性研究#
用戶訪談：
- 一對一深入交流
- 了解用戶的想法、感受、行為
- 發現問題和機會
訪談流程：
├── 開場：介紹目的，建立信任
├── 暖場：聊背景，讓對方放鬆
├── 核心：圍繞主題深入探討
├── 總結：確認理解，感謝參與
└── 記錄：整理訪談記錄和洞察可用性測試：
- 觀察用戶使用產品
- 發現使用障礙和困惑
- 驗證設計假設
焦點小組：
- 多人一起討論
- 收集多元觀點
- 激發新想法
定量研究#
數據分析：
- 分析用戶行為數據
- 找出模式和趨勢
- 驗證假設
問卷調查：
- 收集大量用戶反饋
- 了解滿意度和偏好
- 驗證定性研究的發現
A/B 測試：
- 對比不同方案的效果
- 用數據驅動決策
- 後文「增長與數據」會詳細討論
研究方法的選擇#
什麼時候用定性：
├── 探索階段，不知道問題在哪
├── 需要深入理解「為什麼」
├── 新產品或新功能的早期
└── 數據無法解釋的現象
什麼時候用定量：
├── 驗證假設，確認判斷
├── 需要知道「多少」「多大」
├── 對比不同方案的效果
└── 持續監控和優化用戶畫像（Persona）#
用戶畫像是對目標用戶群體的虛構描述，基於真實研究數據，用於指導產品決策。
為什麼需要用戶畫像？#
- 讓團隊對「用戶是誰」有共同理解
- 做決策時有參考標準
- 避免「我覺得用戶會…」的主觀判斷
- 幫助設計符合用戶心智的產品
用戶畫像的組成#
寶玉建議的畫像模板：
基本資訊：
├── 姓名（虛構但具體）
├── 年齡、職業、收入
├── 居住地、家庭狀況
└── 一張照片（增加真實感）
行為特徵：
├── 使用習慣
├── 決策方式
├── 資訊獲取渠道
└── 相關場景
痛點和需求：
├── 面臨的主要問題
├── 未被滿足的需求
├── 對現有方案的不滿
└── 願意為什麼付費
態度和價值觀：
├── 對產品類別的態度
├── 決策的關鍵因素
├── 擔憂和顧慮
└── 期望和追求用戶畫像的常見錯誤#
| 錯誤 | 問題 | 改進 |
|---|---|---|
| 太多畫像 | 無法聚焦 | 優先級排序，先服務好核心用戶 |
| 太籠統 | 沒有指導意義 | 增加具體細節 |
| 純靠想像 | 脫離現實 | 基於真實研究數據 |
| 做完就扔 | 浪費 | 在決策中實際使用 |
用戶場景（Use Case）#
什麼是用戶場景？#
用戶場景描述用戶在特定情境下如何使用產品解決問題。
場景描述的要素#
誰（Who）：什麼樣的用戶
什麼時候（When）：在什麼情境下
在哪裡（Where）：什麼環境
為什麼（Why）：想達成什麼目標
做什麼（What）：執行什麼操作
怎麼做（How）：具體的步驟示例：
小明（25 歲程式員）在早上通勤的地鐵上（15 分鐘路程），想快速了解今天的科技新聞，打開 App 首頁瀏覽推薦列表，看到感興趣的標題就點進去閱讀摘要，有時會保存到稍後讀。
場景的價值#
- 幫助團隊共情用戶
- 指導功能設計的優先級
- 發現設計中的問題
- 評估方案是否解決問題
需求分析與管理#
需求的來源#
外部來源：
├── 用戶反饋和投訴
├── 用戶研究發現
├── 市場和競品分析
├── 銷售和客服反饋
└── 行業趨勢
內部來源：
├── 數據分析洞察
├── 技術可能性
├── 戰略規劃
├── 內部使用反饋
└── 老闆想法需求評估框架#
邱岳推薦的評估維度：
| 維度 | 問題 |
|---|---|
| 用戶價值 | 解決了多大的問題？影響多少用戶？ |
| 業務價值 | 對業務指標有什麼影響？ |
| 可行性 | 技術上能實現嗎？成本多大？ |
| 緊急程度 | 是否有時間窗口？ |
| 風險 | 做錯了會怎樣？不做會怎樣？ |
需求變更處理#
需求變更是常態，不是例外。問題不在於有變更，而在於如何處理變更。
邱岳的建議：
接受變更：
├── 理解為什麼要變
├── 評估變更的影響
├── 和團隊溝通調整
└── 更新文檔和計劃
拒絕變更：
├── 說明拒絕的原因
├── 提供替代方案
├── 約定下一個版本考慮
└── 記錄以便後續回顧建立需求變更的流程。任何變更都要經過評估和確認，不能隨意改。同時保持一定的彈性，真正重要的變更要能快速響應。
競品分析#
為什麼要做競品分析？#
- 了解市場現狀
- 學習優秀設計
- 找到差異化方向
- 避免重複犯錯
競品分析框架#
產品層面：
├── 核心功能
├── 用戶體驗
├── 定價策略
├── 商業模式
└── 市場定位
公司層面：
├── 公司背景
├── 團隊規模
├── 融資情況
├── 戰略方向
└── 市場份額競品分析的常見錯誤#
| 錯誤 | 問題 | 改進 |
|---|---|---|
| 只看表面功能 | 忽略設計背後的邏輯 | 分析「為什麼這樣設計」 |
| 照抄競品 | 失去差異化 | 學習後結合自身情況 |
| 只看直接競品 | 視野狹窄 | 關注替代方案和潛在競品 |
| 做完就扔 | 浪費 | 定期更新，持續跟蹤 |
本章要點#
- 用戶說的 ≠ 用戶要的：挖掘真實需求和深層動機
- 定性+定量：不同階段用不同研究方法
- 用戶畫像：基於數據，具體生動，實際使用
- 場景驅動：理解用戶在什麼情境下使用產品
- 需求管理：有框架地評估，有流程地處理變更
- 競品分析：學習但不照抄，找到差異化