https://medium.com/as-a-product-designer/%E8%A1%80%E6%B7%8B%E6%B7%8B%E7%9A%84design-sprint%E5%88%9D%E9%AB%94%E9%A9%97-b7b3f76e0f47
自從2016年，無意間在書店買了這本書，看完並初步瞭解了這套方法之後，就一直躍躍欲試，
只可惜，要說服一堆高層，把整整五天都空下來，跟我坐在會議室裡做workshop，真的有很高的難度。
因此，快三年過去了，一直都苦無機會。終於，在2018年底的時候，機會來敲門了。有許多新的規劃將在2019年執行，跟主管幾次討論之後，決定利用12月大家都比較不忙的時候，再來辦一場Design Sprint workshop，初步與主管確認主軸之後，就開始緊鑼密鼓的準備工作了。
時間，總在別人要借的時候，才是最寶貴的
這件事沒有花太多時間，很快就確定了
- 一位首席工程師
- 一位首席產品經理
- 一位資深研發經理
- 三位資深工程師跟我
接著，就是公告我們將再辦一場Design Sprint workshop，請大家挑選出可以配合的時間。結果，說什麼12月大家比較不忙，喬來喬去竟然只能喬出2天
- 最後，首席產品經理要從別的城市飛過來，早上沒辦法參加
- 資深研發經理因為家裡出了點事，第一天只能透過視訊參加
也就是說，五天的workshop，我必須想辦法壓縮在一天半的時間內，而且，還有一個人的第一個半天，得從遠端視訊參加。
在反覆翻閱書本、參考網路文章，再加上與幾位辦過workshop的設計前輩們交換心得之後，總算技巧性地把5天的workshop，切割排列組合，調整成大家都可以配合的議程
就在我滿心歡喜地舉辦workshop啟動會議（Kick off meeting），一心想著，簡單說明一下workshop的議程，就要開始第一個議程：討論2019年的目標（Set a long-term goal），
首席工程師就提出了：『兩天的時間對我們來說是很大的成本，可以解釋一下，為什麼我們需要辦這場Design Sprint workshop嗎？』
真是晴天霹靂，我壓跟沒有心理準備要回答這樣的問題，花了一段時間討論之後，終於瞭解團隊在2016年時，有一個明確的目標與一些模糊的構想，
對於實際要做出個什麼東西來，並沒有頭緒，所以，透過Design Sprint workshop來釐清。對於2019年目標沒變、計畫清晰，缺的只是需要探索如何把這麼多的新功能，在有限的畫面上，適當地呈現給使用者。
面對這樣的問題，我給了不滿意但是還可以接受的答案 - 希望透過這次的會議，探索如何把這些大項目，依照使用者的使用脈絡（ scenarios），合時合地的提供給他們。
思考該怎麼調整，做了一堆功課，再加上經過前輩指導之後，發現竟然已經有Design Sprint 2.0，而且還是經原作者認證過的改良版。
- 縮短成了4天
- 並只要求決策者（Decider）僅需全程參加前兩天。
終於，在參考Design Sprint 2.0的議程，再加上自己的一些調整，總算排出了以下的規劃。
- 設定目標（Set a long-term goal）
- 列舉衝刺問題（List sprint questions）
- 製作使用者體驗地圖（Make a map）
在正式workshop開始前，舉辦一場一個小時的啟動會議，除了大致說明workshop的議程之為，主要著重在上面列出的三個活動。
大家決定這次workshop，直接鎖定兩個經驗地圖，希望在第二天workshop結束時，能夠完成兩套分鏡腳本（storyboard）。製作完使用者體驗地圖之後，就開始分配回家作業。
回家作業是要求每個人，針對三個預設的主題（例如：A與B比較，像是同系列產品不同型號的比較，或是不同付費方案的比較等），分別找出三個以上，最喜歡的設計，接著把這些設計列印出來，帶到workshop當天使用。
- 地圖檢視與分工（Review the maps and divide）
- 設計範例分享（Lightning demo）
- 第一個地圖的設計草稿（4-steps sketching）
- 第二個地圖的設計草稿（4-steps sketching）
第一件事就是
面對面再檢視一次在啟動會議時，畫出來的兩個使用者體驗地圖。
每個地圖各有兩個重點需要設計，因此，分工的方式就是每個人分別從兩個地圖中，各挑一個重點來設計。舉例來說，我們有甲、乙兩個地圖，而甲有A、B兩個重點，乙則有C、D兩個重點，我就挑了『甲 A』跟『乙 D』作為我下午的設計目標。
分工完之後，就是設計範例分享（Lightning demo），每個人利用自己的電腦，把自己前幾天找的設計範例分享給大家，分享的同時，也要簡單說明一下，這個設計範例有什麼值得我們學習的。
在Design Sprint 2.0裏，建議在workshop當天，排25分鐘的時間，讓大家獨自安靜的上網找範例，然而，根據這次的經驗，我很慶幸我請大家在啟動會議後、workshop開始前的這段時間，自己找時間去搜尋範例。因為，我們有三個預設的主題，還希望大家每個主題至少找三個範例，我自己就花了週五一整個下午與週六晚上兩個小時，25分鐘真的會不夠用。我可以理解Design Sprint 2.0會這樣建議是因為，很多人都不會乖乖做回家作業，很幸運地，我的參與人員，最後只有一位沒有作回家作業。
另一個值得慶幸的決定是請大家把回家作業事先印出來，Design Sprint本來的做法是讓主持人（Facilitator），把大家分享的範例，重點式的畫在白板上，然而，我發現，要在有限的時間（每個範例只有2分鐘分享時間）之內，要把範例重點畫出來，真的不是一般人辦得到的。這是我在設計範例分享之後的休息時間，把大家印出來的回家作業貼在白板上。
設計範例分享之後，就是兩個75分鐘的設計草圖，本來規劃每個75分鐘之中，前20分鐘是抄寫目標、衝刺問題與設計方案發想，接著，花10分鐘進行Crazy 8s，最後，45分鐘繪製設計方案。結果，沒有人要抄目標與衝刺問題，因為會議室很小，一眼就看到我寫在白板上的字了，每個人都直接開始畫設計方案，結果，我連Crazy 8s都省略了。
- 設計草圖提案（Solution presentation）
- 熱圖投票（Heat map vote）
- 最高級投票（Super vote）
第一天workshop結束時，我請每個人把設計草圖交給我，本來打算晚上回到飯店之後，自己先看過一輪，以便在隔天一早的設計草圖提案時，可以幫大家總結每一個設計草圖的重點，結果，我真是太天真了。即便前一天，我已經提醒了每個人
第二天的議程首先是，讓每個人安靜地觀看每一組設計圖，並默默地投下自己喜歡的部份
因此，設計草圖必須在沒有人解釋的情況下，還能讓觀看者理解
如果必要，可以加註文字說明。
晚上在飯店看完設計草圖之後，除了我自己的，沒有一組設計看得懂！立刻改變計畫
讓每個設計者，自己解釋自己的設計，解釋完之後，才進行熱圖投票，省略書中的風向投票（Straw poll vote），然後，跳到最高級投票（Super vote）。
Design Sprint 的考量是希望讓所有的設計草圖都是匿名狀態，避免參與者被『誰是草圖作者』而影響的專業判斷。
但是，因為草圖實在太草，我只好賭這個團隊每個人都很專業，並不會為了討好某某人而故意偏向一方
最後的結果證明我賭對了
最高級投票，基本上就是決定哪些設計一定要被考量，並由決策者解釋為什麼，然後，大夥就開開心心去吃午飯了。
- 使用者流程（User flow）
本來，根據Design Sprint 2.0，下午的議程在使用者流程之後，就是要畫出完整的分鏡腳本，以便之後要設計介面原型（prototype）時，有個脈絡，然而，我們卻在使用者流程時，卡關了。
本來的計畫是，請決策者（首席工程師）與首席產品經理一起畫出幾個主要的資料庫效能調校流程，畢竟，這兩位都在資料庫效能管理這個領域，有超過25年的資歷了，想說應該可以輕易完成。沒想到，光討論要畫多細就卡住了，畫得太簡略
跟我們最初在啟動會議畫的體驗地圖沒有太大差異，畫得太細，又有千百種體驗分支，無法逐一列出，最後，只能勉勉強強畫出了兩個流程，就決定不在繼續進行分鏡腳本的繪製，直接利用這個面對面的機會，討論未來三、五年的規劃了。 首席產品經理在努力畫使用者流程（user flow）
這次很多議程都沒有達到原先預期的結果，甚至有些議程，進行到一半我就開始懷疑為什麼要做這個，反而結束的有點草率。
但是，對於將要負責2019年產品設計的我，這次的workshop卻有很大的收穫，我對於產品更了解了、對於計畫更清晰了、對於使用者體驗流程更熟悉了，也就是說，對於2019年的設計，我更有信心在做好用度測試（usability testing）之前，能提出一個80分以上的提案，而且，下次遇到有辦過Design Sprint workshop的人，我應該有更多的問題與經驗可以交流。
關於心得
首先要切記，千萬不要預設大家都不會質疑workshop的正當性 即便團隊已經參加過很多次了，每一次都應該當作第一次來準備，因為，每一次的情況都不一樣，也許，這次需要的真的不是Design Sprint workshop。
其次，對Design Sprint議程熟悉的人，應該會發現我省略了專家訪談（Ask the experts）
- 一方面是因為我們產品團隊非常小，除了我們與真正的使用者，已經沒有其他專家可以找了
- 另一方面是我們團隊的首席工程師跟首席產品經理，都是在這個領域有25年以上資歷的專家，幾乎很難找到使用者體驗地圖的盲點；
最後，2019年的目標早在2016年就定好，還是被多位Director跟VP審核過，因此，我們決定大膽地放棄專家訪談這個議程，目前，看起來也還沒問題。
書中經常提到很多人質疑自己的繪圖能力，這挑戰在我的團隊並不存在，而真正的挑戰在於每個人畫出來的設計提案，真的不是第三者可以看得懂的，因為我省略了Crazy 8s，我不知道會不會有影響，不過，可以肯定的是，下一次辦Design Sprint workshop，我一定要先把期待的成果跟大家要求清楚。
如果可以，主持人最好是局外人，可以專注在議程的進行，很多時候，我知道該進入下一個議程了，但是，團隊正在討論對我設計很有幫助的議題，我就失守了，或者，不知不覺就錯過時間了。有些時候，我又一邊要參與討論，一邊要想著下一個議程的活動，很難專心。也許局外人可以好一些。
當團隊已經非常清楚自己的目標在哪裡、解決方案是什麼時，Design Sprint workshop應該還是一個不錯的方法。
在這種情況下，許多Design Sprint的活動剛開始都有點多此一舉的感覺，但事後想想，幫助團隊再次確認一些事，並確保大家都有一致的共識，其實是很有幫助的。所以，如果你也考慮要在公司辦一場Design Sprint workshop，試著不要專注在流程，專注在每個議程的目的，當然，最重要的是，最後workshop的產出是否能解決你現在面臨的問題。