設計敏捷方法 （Design Sprint Method）是由 Google 提出，且於內部實踐並受到歡迎。它的概念基礎來自於其他已經在產業界應用的方法，例如敏捷開發（Agile）、設計思考（Design Thinking）與革新遊戲法（gamestorming）。這個方法試圖讓每個設計團隊都能輕易的導入，且能於 2~5 天內解決設計挑戰或測試設計原型。
本文介紹的內容整理於 Google 在 2015 年公開的電子工具書 – “Design Sprint Methods“，這本書簡述這個方法中的角色、功效、時間、工具與流程等項目，不過 Google 也指出他們的目的，並非要求大家一定得按表操課，而是鼓勵或激勵新創或任何規模公司的設計團隊，能發展出更有趣、多產且能適應的變通方法。好吧！廢話不多說，以下就讓大舌頭來導讀吧～
設計敏捷方法 初探
團隊成員
Google 建議的團隊人數約 5~8 人，其中包含設計師、工程師、產品經理或相關領域專家（如圖中的團隊即有兩位設計師、一位工程師、一位原型設計師、一位 Sprint Master 與一位研究員）。若團隊人數超過這個建議值，可拆成數個較少人的團隊。並依組織或企業的目標，讓不同團隊面對相同或相異的挑戰。
對團隊的成員構成有初步認識後，我們暫不描述這套方法怎麼運作，而是介紹其中決定專案成敗的重要角色 – Sprint Master 之能力、職責與事項等。
誰是 Sprint Master？她／ 他要做什麼？
基本上，Sprint Master 就是整個團隊的領導者，他們的背景通常是 UX 研究員或設計師，且需要對設計流程、UX 方法論、策略、激勵指導團隊技巧與談判有深度的瞭解。他們最大的任務即是：1）定義設計的挑戰為何、2）建構團隊及 3）帶領團隊跑完整個流程。
“Sprint”是整個流程相當重要的名詞，它指的是解決一次設計挑戰的跌代流程，若要更深入了解可參考敏捷開發的文章
在進行 Sprint 的前中後，Sprint Master 都有不同的事情需要做，該花的時間也不太一樣，我們就由下圖來說明：
Sprint 前
Sprint Master 在此時做的事情相當關鍵。首先，他必須定義好這次設計的挑戰為何？以及工作時程。再來，他必須建構團隊，並用 lightning talks 的方式向成員說明任務與使用者資料，並安排好後續測試的相關細節。另外，若能準備好環境，將會讓 Sprint 進行的更順暢，例如一張大桌子（facilitator’s desk）與討論的空間。
Sprint 中
在 Sprint 開始後，Sprint Master 將扮演促進者（facilitator）的角色，像是掌握時間或節奏、讓每個人都能參與、指派、給予方向、減少溝通摩擦、每日工作檢查、每日發出總結信件與鼓勵讚揚等。有時候議題可能會因為討論而有了新的方向，此時 Sprint Master 也必須快速做出決策，與統合大家的目標。
Sprint 後
當 Sprint 結束後，Sprint Master 須保持帶起來的熱情與衝勁繼續下一個計畫，並將這次 Sprint 的結果紀錄並分享給所有成員，並藉由此次的經驗讓下次的 Sprint 更好。
Sprint 前的準備事項
在開始 Sprint 前，Sprint Master 要設定或選擇好團隊將要面臨的挑戰為何。首先要簡單明確的呈述挑戰的目標，並告知該專注於哪個族群，下方舉個例子：
針對 4~7 歲孩童設計直覺的平板閱讀體驗，並在第四季推出。團隊需產出 mockup 及可點擊的 prototype 供測試。
接著，召開一場與相關權益人的會議，Sprint Master 能從中判斷與學習是否選擇了對的挑戰目標，考量因素包含：1）訪談相關權益人、2）參考現有資料、 3）參考相關的使用者研究報告、4）分析近期相關設計與5）參考使用者案例。
準備好環境、設備與工具
Sprint Master 需將任務時程表規劃好，同時選擇好要應用的方法，例如本書提供的或任何適合的方法。另外，安排一個大桌子，它能在整個 Sprint 過程中起了 “激勵討論” 的效用，當然還會需要一些簡單但有用的小工具，例如：剪刀、紙、膠帶、便利貼、投票貼紙、計時器或響鈴等。最後，若能貼心的準備小點心和咖啡的話，那就更完美了！
進行 Sprint 的流程
跑一個 Sprint 有六個階段，類似 IDEO 提出的 Design Thinking 方法論，簡述如下：
1.釐清與了解（Understand）
使用者需求為何？商業需求為何？技術可行性？
2. 定義（Define）
決定關鍵的策略與應該關注於何者？
3. 發想（Diverge）
如何探索更多的想法？
4. 定案（Decide）
選擇目前最佳概念
5. 原型（Prototype）
做出概念的原型給使用者測試
6. 驗證（Validate）
向使用者、相關權益人與技術專家驗證概念
每個階段都含有許多實踐的方法，例如使用者訪談、競爭者分析或技術分析等。但我們不需要把所有的方法都用上，選擇適合且正確的即可，甚至根據經驗修改或調整過去的方法也行的！
STEP 1. 釐清與了解
360 度（全面） lightning talks
這階段最重要的目的，就是提供不同的觀點來了解問題。這場會議應該包含下述的內容，此外顧名思義， lighting talks 就是要簡短扼要，不用花太多時間。
- 商業上的目標與判定是否成功的指標／5 分鐘
- 技術可行性與可能面臨的挑戰／5 分鐘
- 相關的使用者研究／5 分鐘
競爭者分析
研究 3-10 個相似的產品或服務，列出喜歡或不喜歡的點，這方法可讓我們更快進入狀況也能產生更多靈感。
使用者訪談
我們都知道使用者會是最後使用與評價產品的人，所以這就是為什麼在 Sprint 開始前必須進行此步驟。如果是產品或服務已存在，我們可以問他們會如何使用，對他們的評價是如何；若是一項全新的產品，那我們要更專注於了解使用者覺得哪種解決方式比較好。
田野調查
有時候，訪談使用者不如直接走入他們的工作或操作的環境中來的有用，不但可以了解整個體驗脈絡，也可由中帶回最不失真的訪談。
相關權益人圖表
產品與服務的設計其實不只要關心使用者，所有相關權益人的需求都須考慮進來。我們可以嘗試在 30 分鐘內繪製出相關權益人圖表：
- 首先，陳列所有可能的權益人／10分鐘
- 將這些權益人分組／2 分鐘
- 決定哪些權益人是你在這次 Sprint 的設計對象
- 了解他們的需求
總結學到的資訊並嘗試提出想法
在大家消化前述提到的資訊後，嘗試分享自己的洞見與初步的想法，將它表達於便利貼上。接著，將這些概念分組，並利用小貼紙投票來選出覺得好的概念。不過，最後選出的概念並非一定要往這個方向進行設計，團隊還是可在之後的步驟中，因學習、討論或發現而改變或優化。
STEP 2. 定義
使用者旅程（user journey）
此我們可以透過展開使用者旅程，列出使用者從發現產品或服務、初次體驗、再使用及變的熟練的過程，來整理與分類概念，並定義之後設計的策略。
定義設計原則
定義設計原則的方法很簡單，讓團隊列出認為或希望使用者怎麼描述產品或服務的形容詞，並選出其中最符合的三個。在 Sprint 結束後，你可以請使用者在體驗完 prototype 後說出三個詞彙來比較當初設定的設計原則目標。
想像發佈時的第一則社群訊息
以 Twitter 來舉例，團隊可以想像當產品或服務首次推出時，你會怎麼發出一則貼文。這個方法可以協助團隊在少量文字下表達策略。
STEP 3. 發想
5 分鐘想 8 個概念
這個概念來自於革新遊戲法（gamestorming），是一個暖身的練習方式。每個人都發一張紙，並對摺三次，展開後就有八個區域，接著花 5 分鐘在這八個區域上畫上一些想法。
5 分鐘畫出一個較好的概念
接續上個練習，花 5 分鐘將比較喜歡的一個概念，較精細的畫在一張紙上。
5 分鐘畫出故事情境圖（storyboard）
若概念較複雜不容易表達，我們就可以考慮用故事流程的方式陳述。團隊成員可選出使用者體驗的 “關鍵” 情境將它簡易的畫在分鏡中。（若您的團隊成員對這個方法感到陌生，可以告訴他們就像畫漫畫般）
STEP 4. 定案
靜默投票（Zen voting）
在快速繪製概念後，大家可以將紙貼於板子上，全部看完後進行投票，但規定不能出聲。不能出聲的用意在於，避免因說服或說明後，而影響最初的個人想法。
團隊討論並決定以哪個概念做出原型
團隊可以開始討論哪一項概念是最好的，並決定往下做出原型。此步驟不需要再進行概念發想的動作，例如草圖或探索。
思考帽（Thinking hats）
如果團隊經驗較少或開始對意見有所偏頗或分歧，可以進行思考帽（Thinking hats）這個方法。讓每個成員扮演不同的角色（類似扣帽子的意思，如上圖），並模擬該角色的想法來表達觀點。這樣的做法的目的在於，讓討論更加多元全面。
上圖中的案例中就有五種角色，如：點子王、樂觀主義者、悲觀者、技術專家與使用者專家。
註：此方法是由 Edward De Bone 於 1980 提出，大家可參考這本書 – 六項思考帽。
STEP 5. 原型
原型大家應該都清楚知道，它能讓使用者足以真的感受到有這樣的產品或服務存在，這樣才能得到較不失真的回饋。同時，此書也建議可以花多一點時間在這個步驟中。
STEP 6. 驗證
使用者測試
透過原型進行使用者測試最大的目的，即是快速得到有價值的洞見。以下提供幾個簡單的問題供參考：
- 使用者對原型喜歡與否，其原因為？
- 他們覺得可如何改進？
- 這個解決方案是否能滿足他們所有的需求？
相關權益人確認
概念要持續發展下去，關鍵的權益人掌握了決定權與資源，例如 CEO。所以他們的確認相當重要，是邁向成功的必要元素。
技術可行性確認
確認這個概念所需要的技術是否超過團隊的能力，邀請技術專家評估與討論，可讓後續發展更具可行度。
感想
有些設計師會將創意產出方法與設計方法論視為無用，相信創意的產出來自自我的黑箱（也就是靈感乍現）。事實上，在多元豐富的生活經驗、新事物的刺激、或傳化念頭下，設計師可能會突然產出獨特的創意或解決方法，也因此有些設計師會質疑具有流程、方法及工具的設計方法論，是否能有效的產出創意。
其實這樣的說法，大舌頭不否認，但重點應該視這些思維、流程、方法與工具為參考或激發的手段，畢竟團隊中具有精準洞悉與產出對的創意的人太少，而依靠個人創意所帶來的風險也非常大。因此，不需要對這些創意思考的模式與方法嗤之以鼻（例如設計思考、UX 流程等），這些方法嘗試著如何有效的讓 “每個 ” 團隊進行準確、有效率與低風險的設計，也思考如何在實務上與其他不同專業的團隊合作。
不過，就如這本電子書 Google 提到的，他們也鼓勵各個組織可優化他們提出的方法流程。這點大舌頭認為非常重要，因為每個組織的文化、團隊、員工、設備等皆不同，如果硬要導入一種方法論，也許會造成水土不服而衍生更多問題。所以在對的方向上，應考量現況與團隊適應能力來調整，才有機會將這些思維與方法論帶來的效益發揮出來。最後，若各位讀者對此方法有任何想法，也歡迎在下方留言，大家一起來討論！
衍伸學習書單：
- 設計思考改造世界（鍛鍊思維的好書，大舌頭極推）
- 革新遊戲 Gamestorming
- Google創投認證！SPRINT衝刺計畫：Google最實用工作法，5天5步驟迅速解決難題、測試新點子、完成更多工作！
本文章所屬設計大舌頭與作者所有，未經授權，不得轉載！如需轉載，煩請通知。
