設計衝刺:The Design Sprint – 如何把 Google 的 Sprint 工作術運用在設計團隊?

什麼是衝刺 (Sprint)?

「衝刺」是一個為期五天的過程,目的是 通過設計、設計原型、找出問題、用戶測試 的流程來解答關鍵的商業問題。這個方法由 Google Ventures 開發,GV 團隊將經營策略,開拓創新,行為科學,設計思維,打包成一個實戰檢驗的過程,GV 團隊更稱之為 Sprint 是所有團隊都適用的「創業精選輯」。

在「衝刺」的團隊中一起工作,你可以跳過永遠吵不完的產品開發週期,並且把幾個月的開發時間壓縮至一個星期。

與其等待推出最小的可行性產品,如果可以真正了解什麼是好的想法,就可以從產品原形中得到清晰的數據。「衝刺」給你一個超能力:您可以快進到未來,看看你的成品和客戶的反應--在你花大錢投入開發之前。

設計衝刺:The Design Sprint - 如何把 Google 的 Sprint 工作術運用在設計團隊?
「衝刺」計畫的目的:繞過最花時間的開發階段,直接測試想法。

什麼是設計衝刺 (Design Sprint)?

接下來的項目會教導你如何運行自己的衝刺 DIY 指南。週一,你會找出問題,並且從這些問題中找到值得解決的項目。週二,你會 在紙上設法繪出 各種的解決方案。週三,你會做出困難的決定,把你的想法變成 一個 檢驗的假設。週四,你會敲定高保真原型。週五,你會與真正的用戶測試這個原形。

Design Sprint 的流程
Design Sprint 的流程

在開始之前

開始衝刺之前,你需要有一個正確的題目可以挑戰,並且找到正確的團隊,一個人是沒有辦法進行 Sprint 的。還需要時間和空間來進行你的衝刺。

可以參考:Checklist for Set the Stage


星期一:確定任務

週一的討論會集中在創建一周衝刺的路徑。早上,和你的團隊先確定一個長期的目標。接下來,繪製這個目標的地圖,會在中途遇到什麼困難?要到哪裡去?下午,請教公司內的其他專家,請他們分享一些回饋。最後,你會選擇一個目標:一個雄心勃勃,但是不致於無從下手,讓你可以在一個星期內解決的問題。

延伸閱讀: 週一的準備清單


星期二:畫出草稿

到了週二,你要專注於解決方案。這一天開始的靈感:對現有的想法進行審查,重新組合並且再強化。然後,下午,每個人都照著以下的四個步驟,把自己的解決方案畫出來,強調藝術性上批判性思維。今天也要開始招募最適合自己的目標配置客戶策劃週五的客戶測試。

  1. 筆記。 20 分鐘。安靜的在會會議室內四處走走並且蒐集靈感。
  2. 點子。 20 分鐘。每個人寫下自己的一些點子,並且選擇感覺最有機會的那個。
  3. 瘋狂八。8 分鐘。 把一張紙對摺出八格,並且把上一個步驟的點子化為八種不同可能的樣式,每個方案一格,每格一分鐘。
  4. 解決方案素描。 30-90 分鐘。用三張便條紙畫出產品的分鏡圖,黏在另外一張紙上。美醜不是問題,但是文字說明相當很重要。給他一個讓人眼睛一亮的標題,並且記得保持匿名性。
設計衝刺:The Design Sprint - 如何把 Google 的 Sprint 工作術運用在設計團隊?
週二的四個步驟 圖片來自 brandgenetics.com

延伸閱讀: 週二的準備清單


星期三:選擇方案,做成分鏡

週三早上,你和你的團隊將有解決方案推在一起。這樣很好,但它也是一個問題。你沒有時間把他們一一做成產品原形並且測試,你需要一個更有效的計劃。在早上,你會考量每種解決方案,並決定哪些有實現自己的長期目標的最好機會。然後,下午,你會從這些草圖中拿出大家最認同的,並將其製作成故事分鏡:準備開始一步一步完成你的產品原型。

延伸閱讀: 週三的準備清單


星期四:製作原形,準備測試

週三,你和你的團隊創建了一個故事板。到了週四,你會採取「假的」的理念把這一故事板成雛形。一個現實的外觀是所有你需要與客戶進行測試,這裡是最好的部分:通過關注你的產品或服務的面向客戶的表面上,不要把時間花在調整原形的細節和視覺效果,就可以完成您的原型在短短的一天。這天,也必須確保關於週五的用戶測試沒有問題,再看一下產品原形,採訪的腳本也都要準備好。

延伸閱讀: 週四的準備清單


星期五:訪問你的測試對象

你的衝刺計畫從一個很大的挑戰,與一個優秀的團隊開始。到了週五,你已經創建了一個有前途的解決方案,選擇最好的,並建立了一個真正的產品原型。這本身會作出一個令人印象深刻富有成效的一周。但是你把它一步,你的採訪客戶,通過看他們原型反應學習。這個測試使整個衝刺值得的:在這一天結束時,你就會知道你離目標還有多遠,並且更清楚知道下一步該怎麼做。

延伸閱讀: 週五的準備清單


後記:Sprint 好用嗎?

我在開發團隊的時候,曾經試過很多的方式與很多不同的專案協作、管理軟體,玩了兩三年下來我只有一個心得 :能夠堅持用下去的方式,就是好方式 。不管用什麼工具開發協作管理都好,專案的重點還是要回歸團隊,只要團隊可以接受並且長久的使用,從中建立團隊自己的開發方式不斷修正,最後就會變成一套完整好用的模式。我相信不管是 Srcum 也好、Sprint 也好、甚至是 Waterfall 的開發方式,都是從團隊自己的工作經驗累積修正來的,Google 用自己的經驗得出了 Sprint,我們當然也可以在這個基礎(或是其他基礎)上,創造屬於自己團隊的模式。

Anyway, have a great sprint!
(本文部分翻譯自 GV.com)