lean-ux

精實 UX 框架

一種以實務驅動的 UX 方法，以快速實驗、跨職能協作和持續學習取代繁重的交付物。精實 UX 將問題從「我們應該設計什麼？」轉變為「我們需要學習什麼？」

核心原則

成果重於產出。 設計的價值不在於交付物的精細度，而在於它對使用者行為產生的改變。

基礎： 傳統 UX 將需求瀑布式地轉化為線框圖、模擬圖、規格和程式碼——在每次交接中失去脈絡並隱藏未經測試的假設。精實 UX 壓縮了想法與證據之間的距離：宣告假設、形成假說、執行最小可行的實驗，讓真實的使用者行為來決定勝負。共享理解取代文件；學習速度取代像素完美。

評分

目標：10/10。 使用下方的八行快速診斷來評分 UX 流程、設計計畫或團隊工作流程：每行回答「是」得約 1.25 分（8 個「是」= 10 分）。區間：

• 9-10 — 假設已宣告，假說附有預先承諾的成功標準，最低保真度的實驗，全團隊設計，每週研究，成果（而非產出）指標，雙軌敏捷，以及最近被推翻的假說記錄。
• 5-6 — 假說存在但標準模糊或保真度過度投資；設計和研究仍部分孤立。
• <=3 — 繁重的交付物，未經測試的假設，計算產出，無實驗記錄。

務必說明當前分數、未通過的診斷行以及每項的具體修正方式。

框架

1. 宣告假設

核心概念： 每個設計都始於假設。精實 UX 讓假設明確化，以便優先排序和測試，而不是隱藏在規格中。

為何有效： 未說出的假設意味著團隊在不穩固的基礎上建構，並在發布後才發現問題；及早揭露假設能將精力集中在風險最高的項目上，並降低犯錯的成本。

關鍵見解：

• 商業假設定義了業務必須成立的前提（營收模式、市場規模、支付意願）；使用者假設定義了使用者是誰以及他們的行為模式
• 根據兩個維度進行優先排序：風險（若錯誤的影響程度）和不確定性（我們所知甚少的程度）
• 優先測試高風險、高不確定性的假設
• 以團隊協作方式撰寫假設，而非獨立作業

產品應用：

情境	應用	範例
新功能啟動	假設映射工作坊	「我們假設使用者想要與團隊成員分享報告」
路線圖規劃	根據假設風險排序功能	優先處理成功與否取決於未經測試信念的功能
利害關係人對齊	揭露各角色的隱藏假設	PM 假設定價可行；工程師假設可擴展；設計師假設流程順暢

倫理邊界： 假設必須是誠實的評估，而非事後合理化——如果領導階層已承諾某個方向，請承認這個限制，而不是假裝它可以被推翻。

執行假設工作坊或撰寫假說時，請參閱 references/hypothesis-canvas.md —— 風險/不確定性優先排序矩陣、商業 vs 使用者假設分類，以及可填寫的假說和子假說模板。

2. 假說陳述

核心概念： 假說將假設轉化為可測試的預測，將提議的變更與特定使用者群體的可衡量結果連結起來。

為何有效： 假說強迫精確——團隊不是說「改善入門流程」，而是承諾一個可以被證明或推翻的預測，這能防止範圍蔓延並使學習步驟明確無誤。

關鍵見解：

• 標準格式：「我們相信如果[人物]使用[功能]完成[行動]，將會發生[結果]」
• 每個假說指定人物、行動、結果和可衡量的訊號
• 子假說將大型賭注分解為可獨立測試的部分
• 在執行實驗前，先就「驗證通過」和「驗證失敗」的定義達成共識

產品應用：

情境	應用	範例
功能設計	在繪製線框圖前撰寫假說	「我們相信如果新使用者完成引導式設定精靈，試用轉換率將提升 10%」
A/B 測試	正式化測試理由	「我們相信如果將 CTA 移至摺頁上方，點擊率將提升 15%」
衝刺規劃	為每個故事附加假說	故事：「依日期篩選」。假說：「任務完成時間減少 30%」

倫理邊界： 切勿事後挑選指標來宣稱假說驗證通過——應預先承諾成功標準。

為假說選擇可衡量訊號或定義團隊成功時，請參閱 references/outcome-metrics.md —— 成果 vs 產出、領先 vs 落後指標配對、UX OKR，以及應避免的虛榮指標。

3. 最小可行產品與實驗

核心概念： 精實 UX 中的 MVP 是能夠用真實使用者測試假說的最小設計產物——一個學習工具，而非產品發布。

為何有效： 在走廊上用五個使用者測試紙本原型，就能推翻一個原本需要耗費整個工程衝刺的假說；將實驗保真度與假設風險匹配，能最大化每單位努力的學習成果。

關鍵見解：

• 實驗範圍從低保真度（紙本原型、禮賓測試）到高保真度（編碼 A/B 測試、巫師 Oz 法）
• 選擇能夠回答問題的最低保真度實驗
• 好的實驗有明確的假說、定義的受眾、可衡量的訊號和時間盒
• 當速度重要時，原型人物可暫代完整研究，但之後必須驗證

產品應用：

情境	應用	範例
早期概念驗證	紙本原型或可點擊模擬圖	草繪 3 個概念，同一天測試 5 個使用者
需求驗證	登陸頁面煙霧測試	「註冊搶先體驗」衡量真實興趣
可用性驗證	可點擊原型測試	使用 Figma 原型測試 5-8 個使用者
定價驗證	假門測試	顯示定價頁面，在建置帳務系統前衡量點擊率

倫理邊界： 煙霧測試和假門不得誤導使用者相信產品存在——應揭露測試狀態並提供退出選項。

選擇或設計實驗時，請參閱 references/experiment-patterns.md —— 完整的實驗類型目錄（附何時執行/何時不執行的說明）、實驗選擇矩陣與保真度階梯，以及設計模板。

4. 協作式設計

核心概念： 設計是團隊運動。精實 UX 以跨職能會議取代孤立的設計師然後交接的模式，讓開發者、PM 和設計師共同草繪解決方案。

為何有效： 參與草繪解決方案的開發者不需要 40 頁的規格來建構——共享理解取代文件，多元觀點產生更具創意的解決方案，交接浪費大幅減少。

關鍵見解：

• 設計工作室方法：發散（個人草繪）、展示、評論、收斂（精煉草繪）、迭代
• 目標是知情承諾，而非共識：團隊同意要測試什麼，而非什麼是「對的」
• 跨職能意味著工程師、QA、資料分析師和利害關係人也參與草繪
• 風格指南和模式庫是活文件；將交付物減少到共享理解所需的最小量（通常是白板照片）

產品應用：

情境	應用	範例
衝刺啟動	設計工作室會議（90 分鐘）	全團隊草繪解決衝刺假說的方案
功能探索	協作式草繪工作坊	6 格草繪：每人 5 分鐘畫 6 個想法
遠端團隊	虛擬白板會議	FigJam 或 Miro 白板搭配計時草繪輪次

倫理邊界： 協作不應變成委員會式設計——由指定的設計師綜合輸入；團隊不對像素進行投票。

引導設計工作室時，請參閱 references/collaborative-design.md —— 逐步工作坊流程（時間安排、材料、遠端變體），以及如何將風格指南保持為活文件。

5. 回饋與研究

核心概念： 持續、輕量的研究取代一次性的大型可用性研究——將小型研究活動嵌入每個衝刺，而非季度報告。

為何有效： 研究發現只有在決策仍易於逆轉時才能改變決策，因此研究的價值隨著學習與決策之間的每個衝刺而衰減；小型每週研究能將這個差距保持在接近零，這是季度報告永遠無法做到的。

關鍵見解：

• 研究類型：可用性測試、客戶訪談、A/B 測試、分析審查、問卷調查、日記研究
• 五個使用者可發現約 85% 的可用性問題（Nielsen）
• 持續節奏：每週招募、每週測試、每週綜合
• 整個團隊應至少觀察部分場次以建立同理心
• 原型人物會逐步精煉，最終被基於證據的人物誌取代

產品應用：

情境	應用	範例
每週可用性測試	每週四測試 3-5 個使用者的原型	「測試星期四」儀式，輪流主持
發布後學習	監控分析 + 3 次後續訪談	找出流失點，訪談流失的使用者
人物誌驗證	將原型人物假設與訪談資料比較	「我們假設重度使用者是行銷人員；資料顯示是營運經理」

倫理邊界： 研究應取得知情同意——參與者應了解其資料的使用方式，並可自由退出。

6. 與敏捷整合

核心概念： 精實 UX 透過雙軌開發在敏捷中運作：探索（學習要建構什麼）和交付（建構它）並行進行。

為何有效： 設計工作無法整齊地放入交付衝刺；將探索提前一個衝刺，意味著經過驗證的設計在交付衝刺開始時就已準備就緒，而不是設計永遠在追趕。

關鍵見解：

• 探索軌（研究 + 設計）為交付軌（工程 + QA）提供輸入，錯開一個衝刺
• 使用者故事除了驗收標準外，還附帶假說和成功指標
• UX 的「完成定義」包含經過驗證的學習，而不只是已發布的像素
• 來自被推翻假說的待辦事項應被移除，而非延後

產品應用：

情境	應用	範例
衝刺規劃	將假說驗證納入衝刺目標	「衝刺目標：驗證行內編輯可將任務時間減少 20%」
待辦事項精煉	將實驗結果附加到故事	故事僅在假說驗證通過後才移至交付
回顧會議	同時檢視學習速度和交付速度	「本衝刺我們驗證了 4 個假說，推翻了 2 個」

倫理邊界： 切勿以精實 UX 為藉口跳過無障礙、安全性或合規性——這些是不可協商的品質標準，而非待測試的假設。

將探索融入交付節奏時，請參閱 references/agile-integration.md —— 錯開的雙軌衝刺機制、故事如何攜帶假說，以及 UX 的完成定義。

需要完整的端到端範例來模擬合作時，請參閱 references/case-studies.md —— 四個複合情境（企業、新創、代理商、內部工具），展示假設、實驗以及前後成果指標。

常見錯誤

錯誤	失敗原因	修正方式
將 MVP 視為發布	將 MVP 與首次發布混淆導致過度建構	重新定義：MVP = 學習工具，非產品發布
跳過假設宣告	隱藏假設變成昂貴的意外	在啟動時進行 30 分鐘的假設映射會議
假說沒有成功標準	無法判斷實驗是否通過	預先承諾指標、閾值和樣本數
僅設計師設計	交接浪費、不一致、迭代緩慢	與全團隊進行設計工作室會議
研究作為一個階段	回饋來得太晚而無用	將輕量研究嵌入每個衝刺
忽略被推翻的假說	建構未通過測試的功能	從待辦事項中移除被推翻的項目；轉向或放棄
以文件取代協作	沒人讀的 40 頁規格	以共同設計的共享理解取代規格
衡量產出而非成果	發布不改變行為的功能	將成功定義為行為改變，而非交付

快速診斷

審查任何 UX 流程或設計計畫：

問題	若否	行動
假設是否已明確宣告？	隱藏假設驅動決策	執行假設映射工作坊
是否有可測試的假說？	基於意見建構	在設計前以標準格式撰寫假說
實驗是否為回答問題的最低保真度？	在學習前過度投資	降級為紙本原型或煙霧測試
全團隊是否參與設計？	交接浪費和不一致	安排設計工作室會議
研究是否每個衝刺都進行？	回饋迴圈太慢	建立每週測試節奏
是否追蹤成果而非僅產出？	發布卻無學習	為每個功能定義行為改變指標
UX 工作是否順利融入敏捷？	設計瓶頸或衝刺零陷阱	實施錯開衝刺的雙軌敏捷
能否指出最近被推翻的假說？	未學習；確認偏誤	檢視實驗記錄並慶祝轉向

延伸閱讀

完整方法論、研究和案例研究：

• 《精實 UX：與敏捷團隊設計出色產品》 by Jeff Gothelf & Josh Seiden
• 《感知與回應》 by Jeff Gothelf & Josh Seiden（在組織中擴展成果導向思維）

關於作者

Jeff Gothelf 是一位組織設計師、教練和作者，曾在 TheLadders 和 Neo Innovation 等公司領導 UX 團隊超過 15 年；目睹團隊在未經驗證的交付物上浪費數月，促使他創立了精實 UX。Josh Seiden 是一位設計師和產品策略師，擁有超過 25 年經驗，共同創立了 Cooper 的互動設計實務，並曾任 Neo Innovation 的常務董事。他們共同撰寫了《精實 UX》和《感知與回應》。