No.42 - 設計衝刺的真相
設計衝刺（Design Sprint）指的是團隊以 5 天快跑設計流程，用來處理重要問題。但是，許多設計團隊卻充滿挫折，認為設計衝刺只是個理想。Outreach 分享實際進行設計快跑的狀況，包括要如何準備、心態如何調整，以及最重要的：成果。
Let's GO!
設計衝刺方法論是一場 5 天的設計流程，用於測試想法並解決複雜問題，背後的原則很簡單：開始比正確更重要。首先，必須要將團隊的行事曆必須安排清光一整個禮拜，只用在設計與測試方案，此時，挑戰已經開始，大家會問：為什麼我們需要花整個禮拜的時間來進行？
1. 問題已然發生
當團隊決定下週進行設計衝刺時，很明顯的有一個不得不解決的問題已經展開在眼前，它可能是「快速增長遇到瓶頸」，或是「這個功能可以解決使用者問題嗎？」。從團隊角度來看，要承認問題發生不是一件簡單的事情，牽涉到許多人不太願意面對現實，所以，首先就是要先確認需要設計衝刺的問題範圍有多大。
如果團隊對問題範圍有共識，而且也願意花一些時間處理它，這個時候我們必須要將問題分享出去。進行設計衝刺前，需要訪談一些外部利害關係人，或者是專家學者都可以，確認這是個實際會面臨到的問題。此外，也必須要跟組織內部的產品經理、或執行長談談，總之需要一個可諮詢（可決策）的對象，了解他們的價值觀，最後需要讓他們參與整個決策過程，提供不同視角與建議。
總之，問題本身不會突然出現，相反的它可能存在一陣子，緩慢地吃掉大家的時間，而這正是設計衝刺存在的理由：將無窮無盡的開會時間，集中縮短到可控的範圍，讓大家一起思考。
2. 清晰的目標
就像每個成功的工作坊都始於一個清晰的目標，如果沒有最終目標，你怎麼可能知道自己的解法可以以及如何實現？當需要解決的問題清晰，長期目標應該自然而然地浮現出來。
這常發生在管理層覺得團隊「需要」一場設計衝刺時，可能是某個高層覺得應該要來解決問題，但很有可能的是，團隊並不覺得高層目標是最重要的。此時也會發生一些摩擦，畢竟要讓團隊清空一個禮拜的工作不是一件小事。
正因為設計衝刺的真正魅力在於，它能夠產生切實可行的成果和解決方案。Outreach 的做法是，我們會引導管理層與團隊，將這幾週討論的項目逐一條列，看哪一個問題成為主要問題，其他問題可以先擺一邊。此時，讓大家共同決定目標後再開始，遠比做完後沒有達成效果還來得重要。另外一招就是 Outreach 會直接問衝刺團隊：我們為什麼要這樣做？我們想要實現什麼？我們希望在六個月後達到什麼目標？
設計衝刺結束後，接下來就是將這些成果付諸實踐，並以某種方式落地。清晰的目標設定可以給大家參考，如果產品已經存在，並且團隊設計衝刺專注於改進產品，那麼衝刺成果可能可以立即實現。不過，如果是一個全新的產品或概念，那麼團隊需要一個後續的小型衝刺來驗證想法，思考這是否值得。如果經過測試後發現可以，那麼就能夠融入日常開發節奏。
3. 設計衝刺可以解決所有問題嗎？
不行。
這個答案簡單易懂，但是，為什麼不能？第一個是問題的範圍不大，或過於廣泛（或你可以輕鬆自己解決），設計衝刺並非最佳選擇。就像是每個人都有自己問題需要解決，但不需要過度干涉。另外一個就是要牽涉到專家部分，如果專案需要深入的研究，而不只是一兩天的使用者訪談，那麼設計衝刺可能不是最好的方法。
此外，缺少關鍵成員，就像上面講的產品經理或是執行長沒有加入的話，這可能也會導致問題（以及目標）可能需要更多投入（input），這個也不太適合。最後一個，也是最難的，就是市場需求不夠明確，或者還沒界定，這個時候進行設計衝刺可能太早，收集夠多資訊再進行可能比較好。
最後，也是最真實的一部分，就是團隊本身有沒準備好。
每個人是否願意花一個禮拜解決問題，這跟團隊的主管、個人工作目標、以及期待產出有關係。排除這些障礙，同時也代表著團隊正在進行一場可期待的成果。有些準備工作都不是很容易，像是排會議時間，準備材料，或找可信任的專家等等，而且很容易在開始衝刺前失焦。這些都不會出現在創新教科書上，而是每天、每月、每年累積的小工作坊，造就很棒的設計衝刺。
如果你也對設計衝刺感到厭煩，或許這篇文章可以給你一些感覺，重新思考設計衝刺的意義。
我們有 Facebook 粉絲頁，如果您也能在上面發表對 Outreach 的想法或意見，對於我們很有幫助！此外，您也能夠使用聯絡表單向團隊進行發問。我們會在未來的內容中探索問題的解答。
任何問題都能夠協助我們變得更好！