產品團隊最容易浪費時間的地方，不一定是做得慢。
更常見的是大家很努力，卻在做一個還沒證明值得做的東西。
會議開了很多次。
每個人都有自己的想法。
設計師認為 A 比較直覺。
業務覺得客戶一定要 B。
主管則想把 A、B、C 全部放進去。
最後團隊花兩三個月做出正式版本，真的交到使用者手上，才發現最早那個假設就錯了。
設計衝刺想解決的，就是這種「討論很久、投入很多，卻太晚才知道答案」的情況。
設計衝刺到底在做什麼？
設計衝刺（Design Sprint）由 Jake Knapp 在 Google 發展，後來在 Google Ventures，也就是現在的 GV，逐步整理成完整方法。
經典版本是一個五天流程：
星期一：建立問題地圖（Map）。
星期二：畫出解法草圖（Sketch）。
星期三：做出決定（Decide）。
星期四：製作原型（Prototype）。
星期五：找真實使用者測試（Test）。
這五天最有用的是順序：先縮小問題，再一路走到原型與測試。
團隊先把問題縮小，再產生多個解法，接著做出明確選擇，最後用一個夠真的原型去觀察使用者反應。
這和「先做正式產品，再看看市場喜不喜歡」剛好相反。
設計衝刺適合處理高風險、又卡很久的問題
不是每一個專案都需要五天衝刺。
比較適合的情況通常有幾種。
第一，這個決定一旦做錯，後面投入會很大。
第二，團隊對方向有明顯分歧，會議一直沒有結論。
第三，現在有好幾種看起來都合理的解法，需要快速比較。
第四，團隊準備投入正式設計、開發或行銷預算，但最關鍵的假設還沒有被測過。
例如：
一個新的課程平台首頁，到底應該先讓訪客看課程內容，還是先做需求診斷？
一個新的會員功能，使用者到底看不看得懂操作方式？
一個高價服務的新方案，潛在客戶到底能不能理解價值差異？
這些都比「按鈕要用哪個顏色」更適合用設計衝刺。
第一天：先把問題縮小，不要急著想解法
第一天最重要的工作，是把模糊的大問題變成一個這週真的能處理的目標。
團隊先確認長期目標。
接著列出目前最擔心、最不確定的事情。
再把使用者從開始到完成目標的路徑畫成簡單地圖。
例如一個免費直播報名流程，可以畫成：
看見內容 → 進入報名頁 → 理解主題 → 填寫資料 → 完成報名。
這張圖不需要漂亮。
它的功能，是讓所有人看見「問題到底發生在哪一段」。
如果團隊最後選定的高風險位置是「進入報名頁後，訪客看不懂這場直播適不適合自己」，那這週就先處理這一段。
這週不用把整個網站一起重做。
先定義衝刺問題，比急著找答案更重要
設計衝刺會把風險轉成問題。
例如：
「訪客會相信這個方案適合自己的情況嗎？」
「使用者能在沒有教學的情況下完成第一次操作嗎？」
「客戶能理解三個方案的差異嗎？」
這類問題比「我們要不要重做首頁」更有用。
因為到了星期五，你可以回頭問：我們有沒有得到答案？
如果一週結束後還不知道原本要驗證什麼，代表範圍一開始就沒有縮好。
第二天：先各自想，再一起選
很多工作坊習慣一群人坐在一起腦力激盪。
設計衝刺的做法不太一樣。
它會先讓每個人自己思考、自己畫。
原因很實際。
如果一開始就一起討論，最會說話的人、職位最高的人，或第一個提出的想法，很容易影響整間會議室。
個別草圖能讓團隊先保留更多不同方向。
而且這裡的「畫」不需要繪圖能力。
只要能讓別人看懂使用者會看到什麼、按什麼、接著發生什麼就夠了。
瘋狂八格：逼自己不要停在第一個答案
四步草圖裡很有名的一個練習，叫瘋狂八格（Crazy 8s）。
把紙分成八格，在短時間裡畫八個變化。
它不是要你產生八個完整產品。
這個練習的用途，是把腦中第一個「看起來合理」的答案往外推。
例如原本只想到首頁放一個大標題，畫到第三、第四格時，可能開始出現診斷題、案例選擇、互動比較表或不同的資訊順序。
這些方向最後不一定會用，但至少團隊不會太早鎖定第一個想法。
第三天：不能每個想法都做，必須有人決定
到了第三天，牆上通常會有很多解法。
這時最危險的做法，就是把大家喜歡的東西全部合起來。
因為你最後會得到一個又大、又複雜，而且根本無法在一天內做成原型的方案。
設計衝刺有一個很重要的角色：決策者（Decider）。
團隊可以討論、投票、標記亮點，但最後必須有人對方向負責。
其他人的意見仍然重要，但高風險決策如果最後只剩「大家再討論看看」，整個衝刺就失去作用。
故事板：星期四開始前，要先知道原型要演哪一段
決定方向後，團隊會把使用者實際看到的流程畫成故事板（Storyboard）。
可以把它想成一格一格的漫畫。
第一格從哪裡開始？
使用者看到什麼？
按下哪個選項？
接著看到什麼結果？
最後要測到哪個關鍵時刻？
故事板如果沒有做清楚，星期四很容易一邊做原型、一邊重新討論設計，時間很快就被吃光。
第四天：做一個夠真的原型
這一天很容易做過頭。
設計衝刺不是在一天內開發正式產品。
原型的目標只是讓使用者在測試時，願意把它當成真的東西來理解與操作。
例如網站原型可以用 Figma 或簡報工具做成可點擊畫面。
新服務可以用假的預約流程、銷售頁或角色演練。
新的功能也可以只做使用者會看見的那一層。
後端不一定存在。
資料不一定是真的。
只要不欺騙參與測試的人關於研究本身，而且能夠測到核心假設，就已經有價值。
原型做得太差，測不到真反應；做得太完整，又浪費時間
原型需要一個剛好的真實程度。
太粗糙，使用者只會評論「這還沒做完」。
太精細，團隊又可能把時間花在陰影、動畫、資料串接這些星期五根本測不到的東西。
所以原型只做這次測試會經過的路徑。
其他地方可以是假的，甚至不能點。
這也是設計衝刺很重要的紀律：不要因為已經會做，就順手把正式產品一起做掉。
第五天測試：重點是看使用者怎麼反應
星期五要把原型帶到符合目標客群的人面前，而不是只拿給同事看。
經典設計衝刺會在同一天安排多場一對一測試，讓團隊直接觀察。
測試時不要急著解釋畫面。
如果使用者看到一個按鈕，不知道它是什麼，這本身就是資料。
如果主持人立刻說：「這裡是下一步，你按這個就好。」你等於把原本要測的設計問題藏起來了。
好的訪談更常問：
「你看到這裡，覺得這是做什麼的？」
「接下來你會做什麼？」
「你現在在想什麼？」
然後看使用者實際怎麼做。
五位使用者的目的，是快速找出重複模式
經典做法常用五位目標使用者完成同一天測試。
這個數量的目的不是拿來代表整個市場，也不是要算出精準百分比。
它比較適合找明顯模式。
如果五個人裡有四個都在同一個地方停住，你就得到一個很值得處理的訊號。
反過來，如果不同人反應差異很大，代表你可能還需要更多研究，不能把五個人的意見直接當成市場結論。
現在 GV 也有其他研究型衝刺，會用五位精準招募的目標客戶比較多個簡化原型；這再次顯示「找對受測者」比單純增加人數更重要。
測試失敗，不代表這一週白做
這是設計衝刺最容易被誤解的地方。
如果星期五發現使用者完全不懂原型，有些團隊會覺得「失敗了」。
但如果原本準備投入幾個月開發，現在五天就發現核心方向有問題，這其實是很便宜的答案。
衝刺要降低的，是「太晚才知道方向有問題」的成本。
因此測試結果可能有三種情況。
方向大致成立，可以往下一步做。
部分成立，需要修正後再測。
核心假設不成立，應該換方向。
三種結果都有價值。
設計衝刺、MVP 與開發衝刺是三件不同的事
設計衝刺、最小可行產品（MVP）與開發衝刺（Development Sprint）很容易被混在一起。
設計衝刺的產出通常是一個被測過的原型與更清楚的方向。
MVP 則是能進入真實市場、取得實際使用資料的最小產品。
開發衝刺的目的通常是完成可以運作、可以交付的產品增量。
所以星期五測完原型，不代表星期一就能直接上線。
團隊還需要把測試學到的東西轉成產品需求、技術設計與開發順序。
如果你正在做第一版產品，可以延伸閱讀 從 App 點子到第一個可用版本：哪些事情要先驗證，哪些不要太早做。
什麼情況不適合跑設計衝刺？
如果問題已經很清楚，解法也沒有重大不確定性，只差執行，那就不需要為了流程而硬排一週。
例如：
已知結帳頁某個欄位壞掉，需要修正程式。
法規明確要求新增一段說明。
既有設計系統已經定義好元件，只需要正常製作新頁面。
這些事情直接做通常更有效率。
另外，如果找不到符合目標條件的使用者，或關鍵決策者完全無法參與，衝刺的價值也會明顯下降。
四天版本可以用嗎？可以，但不要只剩「趕進度」
經典版本是五天，但 Jake Knapp 與 John Zeratsky 現在的官方服務也明確把設計衝刺描述成四天或五天的流程。
有些團隊會把 Map、Sketch、Decide 壓縮，保留原型與使用者測試。
壓縮不是問題。
不能丟掉的是這幾件事：
問題要有清楚範圍。
團隊要產生多個解法。
必須做出決策。
要有足以測試的原型。
最後要讓真實目標使用者來驗證。
如果流程最後只剩「大家快速開會做個畫面」，就已經偏離設計衝刺的核心。
課程與知識型事業，也可以借用設計衝刺
不一定要開發 App 才能用。
例如你想推出一個新的高價課程方案，但還不確定客戶能不能理解方案差異。
可以先把問題縮成一段購買決策流程。
接著畫幾種銷售頁結構或方案呈現方式。
挑一個方向做成高擬真頁面原型。
再找符合條件的潛在客戶，看他們怎麼理解。
這會比整套課程錄完、網站全部架好，最後才知道訊息有問題安全得多。
如果還在驗證事業本身，可以先看 從一個想法到真正有人付錢：新事業建立的完整驗證路徑。
跑設計衝刺前，可以先確認這七件事
一、這真的是一個高風險、值得集中處理的問題嗎？
二、這週要驗證的問題能不能寫成一句清楚的衝刺問題？
三、誰是最後決策者？
四、團隊裡有沒有足夠的產品、設計、技術、銷售或客服視角？
五、星期四能不能做出足以測試、但不用正式開發的原型？
六、星期五能不能找得到真正符合目標條件的使用者？
七、測試結果出來後，團隊願不願意真的調整方向？
如果最後一題答案是否定的，這場設計衝刺很可能只會變成一場看起來很忙的工作坊。
設計衝刺省下的是做錯方向的時間
五天不是魔法。
它沒有辦法保證產品成功，也不能取代後續的市場驗證、開發與長期研究。
它的價值，是把原本很晚才會發現的問題，提早到正式投入之前。
星期一把問題縮小。
星期二保留不同解法。
星期三做出選擇。
星期四把想法變成夠真的原型。
星期五讓目標使用者告訴你，團隊原本的想像哪裡對、哪裡錯。
如果一個方向值得投入，五天後你會更有信心。
如果不值得，五天後知道，也遠比三個月後才知道便宜。
常見問題
設計衝刺一定要完整跑五天嗎？
經典 GV 版本是五天，但現在也有四天版本。重點是保留問題縮小、獨立產生解法、明確決策、快速原型與真實使用者測試這幾個核心環節。
設計衝刺做完就能直接開始開發嗎？
不一定。設計衝刺主要產出的是被測過的原型與學習結果。測試通過後，仍需要整理需求、技術設計、邊界條件與開發順序，再決定如何進入正式產品。
一定要找五位使用者嗎？
五位是經典做法，適合在一天內快速找出重複模式，但不是統計上的市場代表。更重要的是招募符合目標條件的人，並把觀察當成產品研究證據，而不是把五個人的反應當成整個市場比例。
小團隊只有兩三個人，也可以跑設計衝刺嗎？
可以。團隊人少時可以簡化角色，但仍要保留清楚決策權、不同觀點、原型與使用者測試。如果缺的是關鍵知識，可以在前期找相關專家補資訊。
設計衝刺和一般腦力激盪最大的不同是什麼？
它不會停在產生點子，而是一路走到決策、原型與真實使用者測試。前期也刻意保留個別思考，避免團體討論太早被少數人的聲音帶走。
參考資料
Jake Knapp, John Zeratsky, and Braden Kowitz. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.
GV. “The Design Sprint.”
Jake Knapp. “Sprint.” JakeKnapp.com.
Jake Knapp and John Zeratsky. “Design Sprint.” TheSprintBook.com.
Jake Knapp. “How to Run 13 Design Sprints at Once: Inside Maker Week at The New York Times.” TheSprintBook.com.