源起
大約在一年多前就知道 Google Design Sprint 這個設計方法論，也買了書來看，看完後覺得好像滿簡單的，但也懷疑這個方法的實用性。不過大約在 3 個月前幸運的參與到 Albert (前 LinkedIn 的 User Experience Designer)回台灣的分享，Design Sprint 這個方法 Albert 他們在美國執行過很多次，也覺得這個方法，有一些機制可以避免其他 Design Workshop 的缺點，產生更有效的結果。所以在 2 個月前就跟同事花了大約 3 週的時間準備，希望可以實際執行，體驗 Design Sprint 的整個流程，並看是否可以做適當的調整並導入到公司內部，來幫公司解決一些問題。
做好準備 (Set the Stage)
在衝刺計畫開始前，需要做的準備有以下幾點：
- 選個大難題
商業機密
- 找一位(或兩位)決策者
- Decider：Harry
- 組織衝刺計畫團隊
- Interaction Designer：Aco
- 2 Product Manger：Luna、Michelle
- Designer：Nana
- Back-end Engineer：Allen
- User Researcher：Jamie
- 安排專家客串
- 4 位專家
- 選一位促進者
- Facilitator：Aco
- 在日程表上空出 5 個天
- 7/10 (一) ~ 7/14(二)
- 預訂一個房間，準備兩塊大白板
5 天的行程表
星期一 – Map Day
關鍵概念
- 以終為始：先想像自己達到的結果，以及可能遇到的風險。然後反過來想出達成目標必預達成的步驟。
- 沒有人無所不知：連決策者也不例外，為了解決團隊的大問題，我們必需釋放這些知識，逼立必要的共同認知。
- 把問題轉化成機會：細心聆聽，注意重要的問題，然後利用「我們可以如何(HMW)」，把問題轉化為機會。
設定一個長期目標
- 我們為什麼要做這個專案?
- 6 個月、1 年、甚至 5 年後我們想取得什麼成就，我們希望自己走到哪裡?
以價值主張的描述句來當我們的長期目標：
Our (product/service) helps (customer segment) who want to (job to be done) by (verb, e.g. reducing, avoiding) and (verb, e.g. increasing, enabling) unlike (competing value proposition)
列出衝刺計畫問題
- 我們希望在這次 Design Sprint 中回答什麼問題?
- 達成我們的長期目標需要哪些條件?
- 如果我們的專案失敗了，失敗的原因可能是什麼?
- 我們有什麼獨特的優勢或機會 ?
- 最大的風險是什麼 ?
畫示意圖
- 列出顧客和關鍵角色，目標完成的情況，5 ~ 15 步驟即可
- 成員先在便利貼上寫下可能的示意圖步驟，之後再跟大家說明，最後選出最有可能示意圖流程
這部份感謝 Jamie 的建議，提醒大家先自己畫面可能的示意圖步驟，完成後大家再一起上來說明，並貼上珍珠板，之後大家再把相似和重要的步驟挑出來，變成初步的示意圖架構
請教專家
- 視需要更新長期目標、問題和示意圖
- 把問題想成是機會，一張便利貼記一個想法
感想：記錄 HMW 需要練習，否則大家會寫得手忙腳亂。專家建議找 2 ~ 3 個即可，一次只訪問一個專家，這樣大家比較容易記錄
選定一個目標
- 在示意圖上選出最重要的顧客和一個目標
- 成員可以表達意見，但由決策者做出最終決定
感想：最後決策者選出一個目標，但因為我們的示意圖分前中後 3 個部分，所以在前中後各選一個重要的目標
Tuesday – Sketch Day
關鍵概念
- 重新組合，加以改良：偉大的創新都是以既有的事物為基礎。
- 人人都能畫圖：多數方案草圖不過是一些框框和文字。
- 具體勝過抽象：利用方案草圖，把抽象的構想轉化為可讓他人評估的具體方案。
- 一起獨自努力：群體腦力激盪不可以，讓每個人有時間獨自研擬解決方案，反而比較好。
閃電型示範
成員輪流用 3 分鐘，介紹看到的出色解決方案。在白板上快速畫出示意圖，藉此記錄好的構想。3 分鐘示範：團隊成員逐一介紹自己推薦的產品，向大家說明該產品的厲害之處。示範過程中在白板上寫下重點。快速畫下這個概念的示意圖，在上想寫一個簡單的標題，並在下方記下資料來源。ex：Google Excel 的嵌入式評論。
感想：由於前一天的目標在大家腦中還是無法有很明確的方向，所以大家找的產品都比較廣泛一點，這邊如果可以的話，或許在 Design Sprint 前就可以請大家先找一下相關的產品或資訊，在這裡會比較容易進行下去。
四步驟畫法
- 筆記：在 War Room 中，蒐集關鍵筆記
- 構想：記一下粗略的構想，圈出最有希望的構想
- 瘋狂 8：在 8 格框中畫出解決方案的 8 個變體，每分鐘 4 格
- 方案草圖：
- 做到不言自明：把方案草圖貼到牆上給大家看，它必須不言自明。
- 匿名發表：不要在草圖上署名。
- 別怕畫得醜：畫一些框框、火柴人，再加上一些文字說明。
- 文字很重要：草圖中的文字對說明構想大有幫助。
- 取個吸引人的名字：這些名字將方便大家評論個方案。
感想：由於上午的閃電型示範比較快結束，所以當下就臨時決定先把筆記、構想、瘋狂 8 這 3 個步驟先完成，這樣下午有一整段的時間來完成方案草圖。但可惜的是沒有跟團隊講好，所以前 3 個步驟進行的有點傖促，一整個下午的時間都是進行個自的方案草圖繪製，不過對於有些人來說時間還是不夠，有些人還拿回家繪製，隔天早上在才完成，感覺整個方案的範圍可能要控制一下，不然真的每個人畫的細致程度有差
Wednesday – Decide Day
關鍵概念
- 避免秏盡力氣：做每一個決會秏費一些精力。遇到困難的決定時，請決策者做決定。小問題可以留到週四再處理。
- 停止新靈感：不要探討新的抽象構想。努力處理既有的構想即可。多數構想在純概念階段會顯得比較誘人，他們實際上可能沒那麼好。
黏貼決策
- 美術館：用膠帶把方案草圖貼到牆上，形成一長列
- 熱點圖：所有人各自瀏覽所有方案，用 1-3 個小圓點標出自己喜歡的部分
- 快速評論：每個方案 3 分鐘，集體討論方案重要之處。把突出的構想和重要的異議記錄下來。最後詢問方案作者：其他成員是否忽略了什麼?
- 稻草民調：每個人私下選出自己喜歡的一個構想，一起用大圓點貼紙投出自己的一票
- 超級票：把 3 張特別票 (上面寫著決策者的名字)，請決策者投票
感想：決策者沒有聽到早上的方案說明，在中午只有一個小時的時間自己看著每個方案，可能受到時間上的壓力和自己對方案的見解，有可能無法完全了解所有方案想要表達解法，感覺上比較可惜一點。所以建議在做黏貼決策時，決策者還是在會比較好，但就像是書上說的，大家的說明只能當作參考，決策者還是要選擇自己得最合適的方案。
製作分鏡角本 (Storyboard)
- 利用即有材料(之前的方案草圖可以把便利貼直接轉貼過來)
- 細節夠用就好(不要集體撰文)
- 困難選擇讓決策者決定(有疑問時，大膽一點)
- 把故事控制在 15 分鐘之內 (經驗法則：每一格分鐘約測 1 分鐘)
- 停止新靈感：不要探討新的抽象構想。努力處理既有的構想即可。多數構想在純概念階段會顯得比較誘人，他們實際上可能沒那麼好。
在製作分鏡角本時，一開始有點卡住，不過還好有大概順出一版本
感想：分鏡腳本真的需要練習，不確定是不是我們的方案範圍太大，所以分鏡腳本無法太順利的繪製出來。當我們繪製時我發現只有 9 格，所以心想似乎可以再想另一個 Scenario，所以我們又繪制出另一個 Scenario (這是一個錯誤的決定… 導致隔天在 Prototype 時有太多畫面需要產出…)，下次會再注意一下分鏡腳本的數量 (不要超過 15 格)。
Thursday – Prototype Day
關鍵概念
- 原型心態：原型是可以被捨棄的，做到剛好能滿足測試需求即可。原型必需看起來夠真實
- 剛剛好的品質：創造出一個品質剛好足夠引起顧客誠實反應的原型
選 Prototype 工具 & 分工解決，已經在 Sprint 前就大致決定了，因為大家都有各自的專業所以很快就可以把工作交給對應的人
- 工具：Sketch、Invision
- 製作者：Nana
- 整合者：Aco
- 採訪者：Jamie
- 寫作者 & 資料搜集者：Luna、Allen、Michelle
Nana 負責所有畫面的 UI，Jamie 有 UR 的專業所以先負責星期五 UR 的整個流程，我負責將 UI 用 Invision 串起來做成可以 Interactive 的 Prototype，Luna、Allen、Michelle 則幫忙 Wireframe 的製作、文案的撰寫和資料的搜集。
感想：這天一整天都在趕做 Prototype，由於前一天沒有控制好 Storyboard 的數量，而且我們的流程也是先把 Wireframe 畫好後再進行 UI 的繪製，所以相對來說花了滿多時間的，應該前一天就先把 Storyboard 的細節先討論好 (收斂後的 Storyboard)，星期四這天就比較會快速把 Prototype 產出，就可以提先試 run 一次整個流程。但實際上，我們當天回到家後還在趕 UI 和整合的部份，並無法在當天下班前試 run 一次。
書上建議是有兩位設計師，但我們只有一位 UI 設計師，所以產出擬真的 UI 只能靠 Nana，不過事後想到是不是 Nana 把視覺風格的規範定出來，我們會用 Axure 的人就可以依視覺風格規範把擬真的 UI 繪製出來 (? 這部份有待討論，可能還是要依團隊實際的狀況為主)
Friday – Test Day
關鍵概念
- 5 是神奇數字：訪問完 5 名顧客之後，大形態已經呈現出來。在一天內做完這 5 個訪問。
- 一起觀看，共同學習：一起觀看顧客受訪的過程，是效率較高的做法，你們也狀得出更好的結論。
- 每次都是贏家：原型可能是有益的失敗或有瑕疵的成功。無論如何，都能得到有用的資訊，知道下一步該怎麼做。
星期五這天的 Test Day 的事項大多都是 Jamie 準備 (非常感謝!)，在前一天我們也設定好觀察室和訪談室的設備。這天要訪問 5 位受訪者一位大約訪問一個小時，半小時來討論和休息。在 Jamie 在訪談時，我們在觀察室把聽到的正面和負面評價寫在便利貼上，休息時候再貼在珍珠板上，在過程中有發現不錯的構想也可以記錄下來。但可惜的是我因為家裡有事，只聽了上午 2 位受訪者，下午就先請假回家了，很感謝團隊繼續把後續的標程跑完，而我們在星期一上午也開了一個小型的衝刺計劃回顧會議，來討論這次的衝刺計劃有哪些部份是做得好的? 我們學習到什麼? 以及有哪些部份是可以改進的?
感想：這天的訪談可以聽到 User 真正的 Feedback，但允許的話可以讓團隊成員交換的訪談，這樣不會讓訪談者太累，也可以學習一些訪談技巧。另一方面我們也聽了之前 Albert 的建議，提前找受訪者，但意外的事本來以為找的受訪者，不是這次衝次計畫的 TA，但訪談完後也發現我們當時提出的假設是正確的，在台灣 80% 的人都會有類似的問題，只差我們要怎麼協助這群人，真是一個大難題，但值得試試!
心得
- 促進者可以專心主導整個衝刺計畫
- UR 方面有專業的同事 Cover
- Sprint 前的準備很重要
- 最好有兩位設計師和一位專門的 UR
- 一定要 5 天嗎? 不一定! 但建議最好 run 一次 5 天的版本
- Design Sprint 很適合拿來做 Team Building，之前 Google 也有拿來做 Team Building
- 決策者如果無法全程參與，建議星期一整天、星期三早上、星期五的早上或下午一定要在，這樣對整個衝刺計畫會很有幫助
- 為了這 5 天準備的精神糧食，
Reference
附錄
acowang 