M10.06｜AI 產品設計思維：使用者需求、MVP 與產品迭代
做 AI 產品不是比技術強弱，是比誰更了解使用者的真實痛點
本講學習重點
AI 產品設計的核心差異：AI 輸出具有不確定性，設計時必須考慮信任、透明度與失敗情境的處理
使用者需求三層次：表面需求（說出口的）、潛在需求（沒說出口的）、核心需求（真正想解決的問題）
MVP 原則：以最少功能驗證核心假設，AI 版 MVP 通常先用人工模擬 AI 功能（Wizard of Oz 測試）
設計思考五步驟：Empathize（同理）→ Define（定義）→ Ideate（發想）→ Prototype（原型）→ Test（測試）
產品迭代循環：Build（建造）→ Measure（測量）→ Learn（學習），每輪迭代都要有明確的假設與指標
AI 產品特有挑戰：資料飛輪效應（用得越多、資料越多、模型越好）需要設計進產品成長策略
北極星指標（North Star Metric）：選一個最能代表 AI 產品核心價值的單一指標作為優化目標
🎙️ Podcast（中文）
一句話搞懂
AI 產品設計思維的精髓是：不要一開始就問「AI 能做什麼」，而是先問「使用者真正在痛什麼」。找到真實的痛點之後，用最小可行產品（MVP）快速驗證假設，再透過持續迭代讓 AI 的能力與使用者需求越來越契合。技術再強，如果解決的不是真正的問題，產品照樣失敗。
白話解說
為什麼 AI 產品特別容易「做偏」？
2016 年到 2022 年之間，有一波 AI 新創浪潮，許多公司拿到融資、組建頂尖的 AI 團隊，用最新的深度學習技術打造了令人嘆為觀止的模型——然後，產品上線之後沒有人在用。
問題出在哪裡？幾乎每個案例都有相同的根本原因：團隊從技術出發，而不是從使用者出發。 工程師問的問題是「我們的模型在 benchmark 上能達到幾分？」而不是「使用者今天早上遇到什麼問題、他們願意花多少時間和金錢來解決它？」
AI 產品設計思維的第一課，就是學會把問題的方向反轉過來。
三層使用者需求：你聽到的不一定是真的需求
使用者研究中有一個經典的洞察來自 Henry Ford（雖然真實性有爭議）：「如果我問客戶想要什麼，他們會說：一匹更快的馬。」使用者描述的是他們的解決方案，不是問題本身。AI 產品設計師必須學會挖掘三個層次：
第一層：表面需求（說出口的） 使用者直接告訴你的需求，例如：「我需要一個自動回覆電子郵件的功能。」這是入口，但不是終點。
第二層：潛在需求（沒說出口的） 透過觀察使用者的實際行為才能發現，例如：他每天花兩小時在重複回覆類似的問題信件，但他不認為這是問題，因為他從來就是這樣工作的。
第三層：核心需求（真正想解決的問題） 再往深挖一層：他真正的需求是「每天下班前能清空收件匣，不把工作帶回家」。一旦找到這個核心需求，設計空間就大幅擴展——也許不需要自動回覆，而是一個更好的優先排序和分類系統。
使用者研究的方法包括：深度訪談（每次至少 30 分鐘，問「為什麼」至少三次）、脈絡觀察（去使用者的工作場域觀察他們實際操作）、使用者日誌（讓使用者記錄一週的相關活動）。iPAS 考試中常出現的考點是：使用者研究和市場調查的區別——前者是質性的深度理解，後者是量化的廣度確認。
設計思考五步驟在 AI 產品的應用
設計思考（Design Thinking）是史丹佛 d.school 提出的以人為中心的創新方法，五個步驟在 AI 產品設計中各有其特殊含義：
步驟一：Empathize（同理） 深入了解目標使用者的生活情境、工作方式、情緒感受。對 AI 產品來說，這一步特別重要的是了解使用者對 AI 的信任程度和恐懼——很多人怕 AI「做錯了沒人負責」或「搶走我的工作」，這些情緒會直接影響產品採用率。
步驟二：Define（定義） 把同理步驟收集到的資訊整理成清晰的問題陳述（Problem Statement）。好的問題陳述格式：「[目標使用者] 需要一種方法能夠 [達成什麼目標]，因為 [有什麼根本原因]。」例如：「醫院護理師需要一種方法能夠快速查閱病患的用藥交互反應，因為值班時間緊迫且同時照顧多位病患。」
步驟三：Ideate（發想） 不限制技術可行性，盡量產生解決方案的可能性。這個階段故意不問「AI 能做到嗎」，而是先把所有可能的解法攤開，再回頭評估可行性。
步驟四：Prototype（原型） 快速建立可測試的低保真原型。AI 產品的原型不一定要真的跑 AI——可以用人工操作模擬 AI 行為（這叫 Wizard of Oz 測試法），先驗證使用者體驗是否符合預期，再投入大量工程資源。
步驟五：Test（測試） 把原型拿給真實使用者測試，觀察並記錄他們的反應，回到前面的步驟迭代。
MVP：最小可行產品不等於最差的產品
MVP（Minimum Viable Product，最小可行產品）這個概念來自 Eric Ries 的《精實創業》，常被誤解為「做一個很爛的版本先上線」。真正的 MVP 定義是：以最少的功能和資源，驗證最關鍵的商業假設。
AI 產品的 MVP 設計有幾個常見策略：
策略一：Wizard of Oz MVP 讓人工假扮 AI。使用者看到的介面像 AI 在運作，背後其實是真人在回應。這個方法能以近乎零的技術成本，快速驗證使用者是否願意使用這個 AI 功能、介面設計是否合理、使用者對 AI 回應品質的期待是什麼。Zappos 早期就是用這種方式驗證線上買鞋市場。
策略二：單一核心功能 MVP 把所有想要的功能砍掉 80%，只保留最核心的那一個。Dropbox 的第一版 MVP 只有一個功能：同步你電腦上的一個資料夾到另一台電腦。沒有協作、沒有分享、沒有版本控制。但這個單一功能就足以驗證最核心的假設：「人們願意把重要檔案存到雲端嗎？」
策略三：Landing Page MVP 在任何功能都還沒開發之前，先做一個說明 AI 產品價值的落地頁，看有多少人願意留下聯絡資訊或預購。如果連興趣都引不起來，就不需要真的去開發。
產品迭代：資料飛輪與北極星指標
AI 產品上線之後，真正的工作才剛開始。傳統軟體可以「做完功能就算了」，但 AI 產品需要不斷用新的使用者資料改善模型效能，這形成了一個資料飛輪（Data Flywheel）效應：使用者越多 → 資料越豐富 → 模型越準確 → 使用者體驗越好 → 吸引更多使用者。
但要啟動飛輪，首先需要選定一個北極星指標（North Star Metric），它必須同時反映使用者獲得的真實價值和業務的長期成長。Netflix 的北極星指標是「訂閱用戶總觀看時數」，而不是「下載次數」或「付費用戶數」。選錯北極星指標，迭代方向就會偏離。
一個 AI 產品的迭代週期通常包含：功能迭代（根據使用者回饋新增或修改功能）、模型迭代（用新資料重新訓練或微調模型）、基礎設施迭代（優化延遲、降低成本、提高穩定性）三個層面，需要產品、工程、資料科學三個團隊緊密協作。
應用場景
| 場景 | 設計方法 | MVP 策略 | 核心指標 | 注意事項 |
|---|---|---|---|---|
| 企業 AI 客服機器人 | 設計思考：觀察客服人員的真實工作流程 | Wizard of Oz：人工客服用 AI 介面回答 | 首次解決率（FCR）、平均處理時間 | 設計「轉交真人」機制，避免客戶卡在 AI 迴圈 |
| 醫療影像輔助診斷 | 深度訪談放射科醫師的診斷流程 | 單一疾病偵測（如肺結節）的概念驗證 | 靈敏度（Sensitivity）、特異度（Specificity） | 法規合規（TFDA 醫療器材）、醫師信任建立 |
| 電商個人化推薦 | 分析使用者購買路徑和放棄購物車的原因 | 基於規則的推薦先上線，收集資料後再 ML | 點擊率（CTR）、轉換率、GMV 提升 | 過度個人化可能引起隱私疑慮 |
| HR 履歷篩選 AI | 訪談 HR 了解篩選標準和常見誤判 | 先做輔助工具（給分參考），不做自動篩選 | 篩選準確率、HR 節省時間 | 演算法偏見風險，需定期審計 |
| 教育自適應學習平台 | 觀察學生上課和做功課的實際行為 | 單一學科、單一年級的概念驗證 | 學習進步率、學生留存率 | 未成年人資料保護（兒少法規） |
| 供應鏈需求預測 | 訪談採購和倉管人員了解目前預測方法 | 單一品類預測，與人工預測結果並排比較 | MAPE（平均絕對百分比誤差）、庫存周轉率 | 季節性和促銷活動需特殊處理 |
| 智慧農業病蟲害辨識 | 田間觀察農民實際操作手機的情境 | 三到五種常見病蟲害的辨識 MVP | 辨識準確率、農民採納率 | 網路訊號差的農村環境，需考慮離線模式 |
常見誤區
誤區 1：「使用者要什麼，我就做什麼」
許多 AI 產品團隊把「以使用者為中心」誤解成「使用者說要什麼功能，我就開發什麼功能」。這個思維的問題在於：使用者通常只能描述他們已知的解決方案，而無法想像他們從未見過的可能性。如果你只是功能請求的執行者，你做出來的充其量只是現有工具的翻版，而不是真正的創新。
真正以使用者為中心的設計，是去理解使用者的目標和痛點，而不是需求清單。使用者說「我要一個搜尋功能」，你應該問「你在找東西的時候，最令你沮喪的是什麼時刻？」也許答案是「我知道我之前看過這篇文章，但就是找不回來」，這背後的需求是「記憶的延伸」，而不只是更強的搜尋。Google Photos 的「找出所有有小狗的照片」功能，就是回應這種更深層的需求。
還有另一個陷阱是「大多數使用者的需求」壓過「極端使用者的需求」。設計師 Ideo 有一個觀點：極端使用者（Extreme Users）往往能揭示產品設計中隱藏的問題，因為他們把普通使用者感受到但說不清楚的摩擦點放大了。
誤區 2：「MVP 就是做一個功能很少的爛產品」
這個誤解導致很多團隊上線了讓使用者失望的第一版，損害了品牌信譽還沒學到有用的東西。MVP 的核心不是「最少功能」，而是「最快驗證」——驗證你對使用者的最關鍵假設。
一個好的 AI 產品 MVP 應該在那一個核心功能上做到體驗完整。Dropbox 的 MVP 只做資料夾同步，但這個功能做得非常好、非常可靠。它沒有很多功能，但它做的那件事讓使用者覺得「這東西真的有用」。相反，一個什麼功能都有但都做得很糟的「大而全」版本，不叫 MVP，叫「Minimum Viable Disaster（最小可行災難）」。
對 AI 產品來說，MVP 還有一個特殊的考量：AI 的輸出有不確定性，使用者對錯誤的容忍度因情境而異。醫療診斷 AI 的 MVP 不能在準確率還很低的時候就讓真實病患使用；而一個推薦餐廳的 AI 偶爾推薦到不合口味的，使用者通常可以接受。MVP 的「最小」標準必須包含「不傷害使用者的底線」。
誤區 3：「上線之後等使用者回饋就好」
被動等待回饋是產品迭代最慢的方式。大多數使用者遇到問題不會主動反應——他們只是默默離開。根據不同研究，只有約 1-5% 遇到問題的使用者會主動反映，其餘的人就是沉默地不再回來使用。
主動的產品迭代需要建立多元的使用者洞察管道：量化面——在產品中埋入事件追蹤（Event Tracking），分析使用者的點擊路徑、功能使用率、流失點；質化面——定期進行使用者訪談（每兩週至少和 2-3 位使用者深聊）；AI 特有指標——追蹤 AI 輸出的品質指標（如使用者對 AI 回應按讚/倒讚的比率、AI 輸出被使用者修改的比率）。
迭代的優先順序不應該由「誰嗓門最大」決定（通常是 VIP 客戶或內部主管），而應該由對北極星指標影響最大的因素驅動。有一個常用的框架叫 RICE（Reach 觸及率 × Impact 影響力 × Confidence 信心度 ÷ Effort 投入），幫助團隊量化比較不同迭代方向的優先順序。
小練習
練習 1：需求挖掘演練
一家保險公司希望開發 AI 產品協助理賠流程。業務部門的需求說明是：「我們需要一個 AI 系統，能自動審核理賠申請單，判斷是否通過。」
請問： (A) 這個需求陳述屬於哪個層次（表面需求/潛在需求/核心需求）？ (B) 你會追問哪三個問題來挖掘更深層的需求？ (C) 設計一個可以在 2 週內完成的 Wizard of Oz MVP 方案。
練習 2：MVP 設計模擬考題
以下哪個選項最符合「AI 產品 MVP 設計原則」？
(A) 盡快上線一個包含所有預期功能但每個功能都尚未完整的產品 (B) 先做一個功能完整但只服務特定小群體使用者的版本，驗證核心假設 (C) 等 AI 模型準確率達到 95% 以上再考慮上線 (D) 讓所有部門主管輪流提供需求，確保各方滿意後再開發