身為促進者你該知道的 Design Sprint (Part 1)
Design Sprint 在2018年榮升為年度熱門關鍵字，相信不少設計師都看過了 Google創投認證！SPRINT衝刺計畫 這本書，在書上大家可以看到完整的 Design Sprint 流程，也有詳細的步驟說明，Whoscall 也嘗試用這個方法論來進行一些大型專案的規劃設計。
Sprint? or Thinking?
我之前寫過的一篇 Design Thinking 文章曾提到， Design Thinking 重點是 Thinking ，Design Sprint 也一樣是在於 Sprint，這也是多數人對於 Design Sprint 的誤解之一，在書中作者不斷強調時間的重要性，甚至列出完美的時間表讓你可以按表操課，你會發現大部分的方法都是為了『不要浪費時間』，而『不要浪費時間』恰恰也是敏捷開發的其中一個原則。
Design Sprint 其實是源自於 Google 創投（後稱GV）的一項方法論，運行的公司多數為新創或是需要在短期內產出，依照這些情境，GV 將需費時許久的 Design Thinking 方法論濃縮成一套接地氣並且快速執行的方式。
曾有國外的文章，將 Design Thinking 與 Design Sprint 比喻成烹飪課程跟食譜的差別，這樣的說法也頗為恰當，詳細可參考本文章：Design Thinking vs Design Sprints, what’s the difference?
回到我個人的解釋，Design Sprint 可視為 Design Thinking 的濃縮版，兩者具有相同的雙鑽石設計過程，Design Sprint 引用了部份的 Design Thinking 方法，但又不全然相同，Design Thinking 著重於人本設計（HCD)，強調從了解用戶開始，而 Design Sprint 則是以如何快速解決難題與提出解法為主要核心。
什麼狀況適合用 Design Sprint？
Design Sprint 針對適合的問題有三個定義需滿足：
時間緊迫的
不知道如何下手的難題
攸關利益的
從這三個定義，你可以看到 Design Sprint 對於能解決的問題有很明確的界線，而這三個定義除去掉『時間緊迫的』，剩下的『不知道如何下手的難題』與『攸關利益的』，正好也是 Design Thinking 的問題定義。
由此可知， Design Thinking 與 Design Sprint 在底層的理論上，其實是可以互通的，雖然兩者的的操作方式不太相同。
以 Whoscall 來說，我們曾經跑過兩次 Design Sprint ，其中一次是我獨自規劃並且擔任促進者，這次經驗讓我獲益良多也踩了不少雷，但礙於本專案還不到可以公開細節的時機，加上網路上也有許多詳解 Design Sprint 每日步驟的文章，所以接下來我以提供個人經驗為主。
首先，促進者是控場角色
若你是一位即將要嘗試 Design Sprint 的促進者，我會建議你先了解一下 Design Thinking 這套方法論的概念與做法。
為什麼我會這麼說？
促進者在 Design Sprint 的角色類似於 Sprint Master，也就代表著你需要引導團隊往某些方向前進，在 Design Sprint 中你的角色非常重要，需要決定何時發散收斂、確保討論順暢，同時去判斷現在的討論的是問題或是解法，甚至在關鍵時刻判斷是否讓決策者決定，促進者若是無法良好的主控全場，或是讓討論亂了套（做出邏輯錯誤的結論），那你們的 Design Sprint 就是一趟直達地獄的超高速列車。
我會認為促進者最好可以擁有 Design Thinking 的相關訓練，在理論上 Design Thinking 跟 Design Sprint 是類比的， Design Thinking 的方法論可以幫助你去判斷現在討論的本質是什麼。
網路上有相關多如何當促進者的文獻與教學，其中推薦 Design Sprint Academy 所撰寫的 Design Sprint Master — Facilitator’s Guide ，這一份約莫69頁的文件，應該會對你幫助非常大。
以外，就我個人身為促進者的經驗，有三個建議可以提供給大家：
1. 充分的前期準備
促進者無疑是整個 Design Sprint 中最辛苦的角色，除了我前面建議的 Design Thinking 的前備知識之外，包含前期規劃、準備材料、約訪專家、確認糧食足以讓大家滿意（這很重要相信我），在 Design Sprint 開跑前夕，建議促進者可以提供一份 Sprint 說明以及流程表給團隊。
2. 精準掌控時間
Design Sprint 開跑後，身為促進者的你必須成為團隊中最客觀的角色，時間與流程是你最大的任務，每一分鐘你都要觀察團隊的情緒與討論的節奏：目前的討論是否恰當、針對目前的議題可以提醒哪位團員發言、是否該讓決策者決定，為了確保討論可以順利結束，你必須對於時間擁有 100% 的專注力。
3. 了解每個流程的用意
最後，相信很多人都是看了 Google創投認證！SPRINT衝刺計畫 這本書而決定要嘗試 Design Sprint，但若只是按照書中的流程操作，沒有了解其中的用意，那麼你很有可能會綁死在流程上動彈不得，甚至在遇到卡關狀況不知道該如何引導團隊，我會建議大家去對照一下有名的 雙鑽石設計流程(The Double Diamond Design Process)，想一下 Design Sprint 每一天的流程（甚至每個階段）可以對應到哪個環節，這可以更快幫助你理解。
因為若是死死地按照書上的做法去執行而不想為什麼，很容易會讓你陷入討論的死胡同，也會讓團隊成員感到心累。
經過三個建議的分享，希望大家對於要擔任促進者之前該做什麼功課，已經有了初步了解，接下來呢？等到開跑之後在每個環節又該注意什麼？
後面的篇幅我將會花一點時間解釋第一天該注意的事項：
第一天的重要性
為什麼我要花一篇文章的篇幅來講第一天？
第一天基本上會著重在於定義目標與問題，這天會影響你接下來四天的走向與解法的產生，第一天的討論量就我經驗來說可以說是最多、最累的，很多不同的想法與意見需要被挖掘與歸納，這時候正是促進者派上用場的大好時機：
先帶領團隊找出問題領域
Design Sprint 一開始會讓大家對於目標的進行定義，在這環節上成員很容易因為是第一次執行，造成大家面面相覷不知道要說什麼，此時促進者的角色很重要，如何引導大家慢慢進入狀況是你的第一任務，我會建議促進者可以嘗試用麥當勞理論，利用一些爛點子去打開話題。
在這個環節建議大家先從樂觀角度出發，再反向用悲觀角度去討論，在這環節促進者要注意，我們要的不是解法，解法在現階段都是不需要的，引導成員去做出假設，再將假設轉化成問題，最後凝聚成目標才是此環節的意義。
精準掌握示意圖的進度
示意圖就理解而言是簡易版的 Journey Map，在設計師的想像中感覺是很容易完成的。
不，你錯了！
在我們做過的 Design Sprint 中示意圖可以說是大魔王，每一次都會卡在這個環節到天荒地老，最後發現剩下十分鐘可以畫圖，屢試不爽。
以個人經驗來說，在繪製示意圖時會希望這個圖可以盡善盡美，這意味著非常多的使用者類型、使用者流程，非常多的歧義與探討，其實示意圖的用意是為了讓主要的故事線視覺化，協助接下來的專家訪談與後續的問題回對，在短短的三十分鐘至一小時內，我們不可能達到 100% 的準確，只要示意圖能夠達到闡述主要故事線就足夠。
Stéphane Cruchon 所撰寫的 The Design Sprint Note-n-Map，針對示意圖產生了一套新的跑法與建議，若未來計劃想跑 Design Sprint 的促進者，建議可嘗試看看。
簡單說明 HMW Methods 的精妙之處
HMW 其實是一種 Design Thinking 經常使用的方法，相信大家應該不陌生，但唯一可能會造成問題的是大家對於 HMW 的寫法，HMW 是一種開放性的問題，目的是為了讓成員在訪談的過程，經由專家給予的 Insight 從中轉化為問題，這是一項需要經驗的轉化過程，Design Thinking 的相關文獻探討中，對於 HMW 的寫法有很多建議，建議促進者可以花點時間看一下相關文獻。
INTERACTION-DESIGN 這篇文章對於 HMW 有一些不錯的建議，另外加碼 POV 的解釋。
隨時重新檢視問題與任務
這是第一天的重頭戲，我們畫了示意圖、做了專家訪談、寫了一堆 HMW、投了票，做了一堆事情，是為了去定義我們接下來要朝哪個方向衝刺，這裏我們需要花點時間去回對之前的衝刺目標與示意圖，看看我們投票出來的 HMW 可以回對到哪個階段的關鍵任務，而這個關鍵任務是否與我們的衝刺目標吻合。
在這個階段會發生很多討論，例如： HMW 與關鍵任務對不上或是與衝刺目標無法吻合，大量的討論與定義會重複發生，有些許的不同在於：Design Thinking 是以了解用戶做為開端，接著才會進入定義問題的階段。在這前提之下，Design Thinking 的定義問題階段是會擁有足夠的 User insights 去支撐你定義問題，但 Design Spint 則是反過來先定義了問題（這時候我們只有 Stakeholders insights )，到最後一天才會獲得 User insights，這是兩個方法論在操作上的不同。
Design Sprint 是一個需要高度對焦並且不斷迭代的流程，在時間的限制下，我們往往很難在一開始就瞄準到正確的領域，但經過與專家的訪談以及團隊的發想，我們才能做最後的調整，可以視為一種 Pivot 的時間點，在這個時間點我們藉由一整天的資料蒐集（目標、專家訪談、HMW），去探討我們真正該瞄準的問題領域是什麼，而在最後的這個環節，我們要做的事情就是為這一整天下個定論，而這個定論會影響到你後面幾天產出的解決方案。
我建議團隊可以做一次總體的大檢查，這時候四周應該有許多材料，四處看看、激發討論，重新思考在這個環節中是相當重要的，在 Design Thinking 中有一個方法叫做 Reframing Problem，問題的定義會依照主觀意識而有不同的認知，舉例而言：
問法 1：「為什麼這杯水只剩一半？」
問法 2：「為什麼這杯水還有一半？」
明明闡述的是同一件事實，卻因為主觀的意識下而有微妙的不同，這就是定義問題的精妙之處，只剩一半跟還有一半，在問題詮釋上擁有大大的不同，所引導出來的解法也會大不相同，Fast Company 曾經發表一篇文章：Three Ways To Reframe A Problem To Find An Innovative Solution ，其中的一些訣竅應該可以幫助你修正問題。
*水杯問題是一種簡單的解釋，若是想了解更多可以搜尋「框架效應」。
超高速列車準備出發
如同我在文章開頭提到的，Design Sprint 很可能會變成一場災難，在我自身帶領的經驗中，我發現第一天雖然以工作量來說並不是整個五天中最繁重的，但卻是這五天當中最重要的，這一天的討論、決策、問題空間等等，將會決定你接下來要往哪一條軌道走。
Design Sprint 宛如一台最新上線的高速列車，大家都希望能夠買到一張車票試乘，期望這台車可以順利帶往他們到達夢想之地。
但在這台列車上，發生了神秘殺人案，而你們需要一起合作推理出犯人….，沒錯就是這種神展開，這種腦洞大開的劇情是確切會發生在 Design Sprint中，你永遠無法預測你可以獲得什麼成果。
Design Sprint 是一種新創團隊探索問題的模式，你無法保證解法或是問題領域是否能夠確切落地，很可能在途中就感覺到有些怪怪的，這可能會讓你產生懷疑與困惑：
我＿＿的在做什麼？！
Design Sprint 是過程論
就我自身的經驗來說，Design Sprint 的成果不一定適用於落地的產品開發，雖然在相關書籍中你會發現 Blue Bottle 的創新成功案例、Slack 的創新成功案例等等，但大家似乎忽略了一件事，創新這件事本來就存有 99% 的失敗率（不然為何每年倒一堆新創公司），你要創新成功絕對不可能只靠一個 Design Sprint。
大家看到這裡應該會想說，那我們為什麼要嘗試 Design Sprint？我也曾經問過自己這個問題，然而在我跑過兩次不同主題的 Design Sprint，我發現到：
在這五天中團隊成員的討論、貢獻、對焦重點、默契培養，獲得的好處遠遠大過成果。
Design Sprint 的好處在於團隊成員一起將數個月的討論流程，濃縮在五天中發生，這五天中你可以真的坐下來，挽起袖子去討論問題、去釐清定義，這些往往該做卻一直被忽略的環節。
你可以將 Design Sprint 當作一個產品（或模式）的開頭，它協助你踏出了第一步，確保你知道你自己在做什麼，Design Sprint 是一個加速器，給予你與戰友足夠的推力往前探索，因為 Design Sprint 是一個過程論，非結果論。
下一篇文章我將會著重在第二與第三天做分享與建議，希望大家不要轉台，鎖定Whoscall 設計師們的學習筆記 :)
