很多產品團隊的設計流程，看起來很完整：
先做需求文件，再做使用者流程、線框圖、視覺稿、規格文件，最後交給工程開發。
問題是，這一整套流程可能做了幾週甚至幾個月，卻沒有人實際驗證：使用者到底需不需要這個東西？
Lean UX 處理的就是這個問題。
它把設計焦點從「我要交付什麼設計文件」移到「我現在最需要學到什麼」。
精實使用者體驗（Lean UX）的核心：成果（Outcome）比產出（Output）更重要
Output（產出）是你做了什麼：
- 完成 20 張設計稿。
- 交付 5 個功能。
- 做完一套 Design System。
- 完成新版首頁。
Outcome（成果）則是使用者行為真的有沒有改變：
- 更多人完成註冊。
- 使用者更快完成任務。
- 第一次操作失敗率下降。
- 更多人找到自己需要的功能。
Lean UX 要求團隊把成功標準放在 Outcome，而不是「東西有沒有做完」。
一個功能做完了，不代表問題被解決
這是產品團隊很容易掉進去的陷阱。
某個功能準時上線、畫面也做得漂亮，團隊就宣布成功。
但如果使用者根本不用，或用了之後行為沒有改變，這個 Output 仍然可能沒有價值。
所以 Lean UX 的第一個問題不是：
「我們要做什麼功能？」
而是：
「我們想讓哪一群使用者產生什麼不同的行為？」
第一步：把 Assumption 寫出來
所有產品設計都建立在 Assumption（假設）上。
例如：
- 我們假設新手不知道第一步做什麼。
- 我們假設加入導覽會提高啟用率。
- 我們假設使用者願意在手機上完成付款。
- 我們假設這個功能是續訂的主要原因。
如果這些假設沒有被寫出來，它們會被默默當成「事實」。
等產品上線後才發現錯了，成本通常已經很高。
假設盤點（Assumption Mapping）：先找最危險的假設
假設不需要全部同時驗證。
比較有效的做法，是用兩個軸來排序：
- 風險：如果這個假設錯了，影響有多大？
- 不確定性：我們現在到底有多少證據？
高風險、高不確定的假設，應該最先測。
因為如果它錯了，整個方案可能根本不值得繼續做。
不要先解決最容易的問題，要先驗證最可能讓整個方向失敗的問題
團隊很自然會先做容易有進度感的事情，例如調整顏色、補幾個頁面、把稿畫完整。
但 Lean UX 會問：
「如果只能驗證一件事，哪個答案最可能讓我們改變方向？」
例如一個新功能最大的風險，可能根本不是介面長什麼樣，而是使用者沒有這個需求。這時應該先驗證需求。
第二步：把 Assumption 轉成可以被推翻的 Hypothesis
Hypothesis（假設命題）和一般想法的差別，在於它必須能被驗證。
一個實用格式是：
我們相信，如果某一類使用者透過某個方法完成某個行動，就會產生某個可觀察結果。
例如：
「我們相信，新註冊的講師如果在第一次登入時看到三步驟設定引導，首次完成課程建立的比例會提高。」
這樣就比「我們要改善 onboarding」清楚很多。
成功標準要在實驗前先決定
如果實驗做完之後才挑數字，很容易出現 Confirmation Bias（確認偏誤）。
數據不理想，就換一個指標說「其實效果不錯」。
Lean UX 更穩健的做法是，在實驗開始前先說清楚：
- 看哪個指標。
- 什麼結果算支持假設。
- 什麼結果代表假設需要修改。
這樣團隊才不會只接受自己想看到的答案。
第三步：最小可行產品（MVP）是學習工具，不一定是正式產品第一版
最小可行產品（MVP）常被誤解成「先做一個比較陽春的版本上線」。
在 Lean UX 裡，更重要的問題是：
驗證這個假設，最小需要做到什麼程度？
答案可能只是：
- 紙上草圖。
- 可點擊原型。
- 一頁到達頁（Landing Page）。
- 人工 Concierge Test。
- 一個 Smoke Test。
如果一張草圖就能證明方向錯了，就沒有必要先寫兩週程式。
低擬真可以降低「證明自己沒錯」的成本
設計稿做得越精緻，團隊越容易產生心理投入。
大家花了一週做好高擬真 Prototype，測試時就更容易想證明它是對的。
低擬真實驗的價值，是讓團隊更容易接受：
「這個方向不行，我們換。」
因為捨棄成本比較低。
不同問題，需要不同 Experiment
| 想知道什麼 | 適合的實驗 |
|---|---|
| 使用者有沒有這個需求 | 訪談、Landing Page、Smoke Test |
| 流程看不看得懂 | 紙上原型、可點擊 Prototype |
| 新介面能不能完成任務 | Usability Test |
| 哪個版本效果較好 | A/B Test |
| 完整服務是否值得做 | Concierge Test、Wizard of Oz |
實驗方法沒有高低之分，重點是能不能回答目前最重要的問題。
不是所有事情都能拿來「測看看」
Lean UX 強調實驗，但不代表所有要求都可以先放掉再觀察。
無障礙、安全、隱私、法規、資料保護等底線，通常不是「如果使用者沒抱怨就算沒問題」的假設。
這些更接近 Non-negotiable Quality Standard（不可妥協的品質標準）。
適合拿來驗證的，是「哪種流程比較容易完成」「使用者是否需要這個功能」「哪一個訊息更能幫助理解」這類產品與體驗假設。
第四步：Collaborative Design，不要讓設計變成接力賽
傳統流程很像：
PM 寫需求 → Designer 畫稿 → Engineer 開發 → QA 測試。
每次 Handoff（交接）都可能丟失背景。
Lean UX 更強調 Collaborative Design（協作設計）：產品、設計、工程、資料與其他相關角色一起參與問題定義與方案探索。
這不代表每個人都變成設計師，而是讓重要限制更早被看見。
設計工作坊（Design Studio）：大家先分開想，再一起收斂
Design Studio 是一種常見協作方式。
流程可以很簡單：
- 先定義要解的問題。
- 每個人各自快速畫方案。
- 輪流說明。
- 團隊提出問題與觀察。
- 挑出值得進一步測的方向。
這樣可以避免一開始就只剩一個人的方案。
協作不等於 Design by Committee
這一點很重要。
Lean UX 鼓勵多角色輸入，但不代表每一個像素都用投票決定。
團隊一起建立 Shared Understanding（共同理解），最後仍需要有人對設計整合與品質負責。
目的在於讓大家知道「我們現在要測哪一個假設」；所有人都同意並不是必要條件。
第五步：Research 不能等到產品快做完才開始
如果研究只在專案開始做一次，或上線前才做一次 Usability Test，很多問題已經變得很貴。
Lean UX 更重視 Continuous Research（持續研究）。
不一定每次都要做大型研究，可以是：
- 每週找幾位使用者做短測試。
- 看一段新功能的 Session Recording。
- 訪談剛流失的使用者。
- 分析客服問題。
- 觀察任務完成率。
重點是讓回饋離決策不要太遠。
使用者測試不是問「你喜不喜歡」
很多研究會問：
「你覺得這個設計怎麼樣？」
這種答案很容易受到禮貌與個人偏好影響。
更有效的方法，是給使用者一個真實任務，觀察他能不能完成。
如果你要進一步檢查可用性問題，可以搭配Nielsen UX Heuristics：使用者看不懂、找不到、一直犯錯，可以怎麼檢查。
第六步：文件要夠用，不要把文件當產品
Lean UX 並不是「不要文件」。
它反對的是大量文件被當成工作的終點。
文件應該服務幾個目的：
- 幫助團隊共享理解。
- 保留重要決策。
- 讓實作不需要重新猜。
- 讓後續能追溯假設與結果。
如果一份 40 頁規格沒有人讀，它的完整度就沒有太大價值。
當工程師一起參與使用者測試、設計師一起看數據、PM 一起畫方案，很多背景就不需要重新寫成厚厚文件再傳一次。
這不代表資訊不用留存，而是「共同參與」本身可以降低交接成本。
第七步：把 UX 工作放進 Agile，而不是永遠提前一個大階段
Lean UX 常和 Dual-track（雙軌）工作方式搭配。
一條是 Discovery（探索），持續驗證接下來值得做什麼；另一條是 Delivery（交付），負責把已經較有信心的方向做出來。
兩條會持續交換資訊，不是完全分開運作。
探索（Discovery）的目標，是降低不確定性
探索階段應該減少不確定性。
如果探索階段只是提前把更多功能寫成 Story，卻沒有驗證假設，那仍然只是另一種瀑布流程。
更好的判斷是：
- 哪一個假設被驗證了？
- 哪一個假設被推翻了？
- 哪一個功能因此不用做了？
被推翻的假設命題（Hypothesis），可以省下一筆成本
這是 Lean UX 很重要的文化。
如果一個低成本實驗證明方向不對，團隊應該高興，因為它阻止你投入更大的開發成本。
只有「永遠驗證成功」的團隊，反而要小心。
那可能代表假設寫得太模糊，或團隊只挑支持自己的資料。
建立 Experiment Log，避免同一個假設被重複討論
團隊做過很多實驗，如果結果只留在某次會議或某個人的記憶裡，半年後很容易重新爭論同一件事。
Experiment Log（實驗紀錄）不需要很複雜，至少記錄：假設、測試方法、對象、成功標準、結果、最後決策。
這樣新成員能理解為什麼某個方向被放棄，也能避免「以前試過但沒人記得」的浪費。
更重要的是，團隊能看見哪些假設被推翻。如果紀錄裡永遠只有成功案例，反而值得檢查團隊是不是只在尋找支持自己的證據，而沒有真的學到新東西。
成果指標（Outcome Metric）應該靠近使用者行為
例如：
| Output | 更接近 Outcome 的指標 |
|---|---|
| 完成新版 onboarding | 首次任務完成率提高 |
| 新增搜尋功能 | 找到目標內容的時間下降 |
| 重做結帳頁 | 付款完成率提高、錯誤率下降 |
| 建立新儀表板 | 使用者完成決策所需時間下降 |
如果只能證明「我們做了很多」，卻無法證明使用者變得更成功，Lean UX 會認為還沒完成學習。
介面重構（Refactoring UI）和精實使用者體驗（Lean UX）的差別
兩者很容易被混在一起。
Refactoring UI 比較偏視覺層級、間距、排版、色彩與介面質感；Lean UX 則更關注「這個設計假設要不要存在、應該怎麼驗證」。
如果方向已經確定、問題在視覺完成度，可以看Refactoring UI：沒有設計師，也能讓介面從業餘感變得專業嗎。
如果連方向本身都還不確定，就不應該太早投入大量視覺細節。
精實使用者體驗（Lean UX）最常見的 7 個錯誤
| 錯誤 | 更好的做法 |
|---|---|
| 一開始就畫完整高擬真稿 | 先驗證最高風險假設 |
| Hypothesis 沒有成功標準 | 實驗前先決定指標 |
| MVP 當正式第一版 | 把 MVP 當學習工具 |
| 設計師一個人完成設計 | 讓跨職能團隊一起參與探索 |
| 研究只在專案開頭做 | 建立持續研究節奏 |
| 只追交付數量 | 追使用者行為改變 |
| 假設被推翻後仍然照做 | 刪掉、轉向或重新定義 |
一個實用的 Lean UX 流程
- 先說清楚想改善哪個使用者 Outcome。
- 列出目前依賴的 Business Assumption 與 User Assumption。
- 找出高風險、高不確定的假設。
- 把它寫成可驗證 Hypothesis。
- 先決定成功與失敗標準。
- 選最低成本、能回答問題的 Experiment。
- 和真實使用者測試。
- 根據證據保留、修改或放棄方向。
常見問題
精實使用者體驗（Lean UX）是不是代表不用做完整設計？
不是。它要求把「什麼時候值得做完整設計」往後移。方向還沒驗證時先用低成本方式學習；確定值得投資後，再提高完成度。
精實使用者體驗（Lean UX）只適合新創公司嗎？
不是。成熟產品、企業內部系統與大型團隊也能使用，只是實驗方法、合規要求與決策速度會不同。
最小可行實驗（MVP）一定要真的上線嗎？
不一定。只要能回答目前的假設，紙上原型、可點擊 Prototype 或人工服務都可能是有效 MVP。
使用者研究每次都要很多人嗎？
不需要每次都做大型研究。Lean UX 更看重研究頻率與決策距離，可以先用小型研究持續找明顯問題，再視風險決定是否擴大。
團隊一起設計會不會變得沒有人負責？
不應該。跨職能參與是為了增加資訊與共同理解，最後仍需要清楚的產品與設計責任。
精實使用者體驗（Lean UX）最重要的改變是什麼？
從「我們做了什麼」改成「我們學到了什麼，以及使用者行為有沒有因此變得更好」。
精實使用者體驗（Lean UX）的價值，是更早發現方向可能錯了
設計流程最昂貴的情況，往往是花了幾個月把錯誤假設做成完整產品；草圖畫錯本身反而便宜得多。
Lean UX 把風險往前拉：先說出假設、先找不確定性、先用最小實驗學習，再決定值不值得繼續投入。
當團隊開始用 Outcome 衡量成果、願意接受假設被推翻，也讓設計、產品與工程共同參與學習，UX 就不再只是「做出一套漂亮介面」，而是持續降低做錯產品的機率。
參考資料
Jeff Gothelf、Josh Seiden：Lean UX: Designing Great Products with Agile Teams。