血淋淋的Design Sprint初體驗

James Liu
James Liu
Dec 26, 2018 · 12 min read
Image for post
Image for post
Sprint成員在解說自己的設計

Design Sprint一般來說,是指一套在Google Venture裏,透過五天、一連串的活動,來驗證一個商業構想或困難的方法。自從2016年,由Jake Knapp跟John Zeratsky與Braden Kowitz三人一起把這套方法整理並出版了『Sprint — How to solve big problems and test new ideas in just five days』一書之後,業界就有不少公司、創業團隊,利用這套方法來調整方向與策略,版面關係,有興趣的人可以去找那本書來看,中文版的在這裡

幸福來得太突然

自從2016年,無意間在書店買了這本書,看完並初步瞭解了這套方法之後,就一直躍躍欲試,只可惜,要說服一堆高層,把整整五天都空下來,跟我坐在會議室裡做workshop,真的有很高的難度。因此,快三年過去了,一直都苦無機會。即便如此,這段期間,只要聽到有團隊或設計師,要辦Design Sprint的經驗分享,我都會想盡辦法去參加,終於,在2018年底的時候,機會來敲門了。

2018年8月,轉到了的Amazon RDS Performance Insights團隊,該團隊在2016年剛成立時,就曾經執行過一次Design Sprint,並把當時的成果,在2016年底推出上線,快兩年多過去了,有許多新的規劃將在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參與過了,啟動會議之前,問大家對於2016 workshop的心得,也都說很有收穫,怎麼會現在突然冒出這樣的問題來!?花了一段時間討論之後,終於瞭解團隊在2016年時,有一個明確的目標與一些模糊的構想,對於實際要做出個什麼東西來,並沒有頭緒,所以,透過Design Sprint workshop來釐清,理所當然。但是,對於2019年的計畫,目標沒變、計畫清晰,缺的只是需要探索如何把這麼多的新功能,在有限的畫面上,適當地呈現給使用者。

面對這樣的問題,我給了不滿意但是還可以接受的答案 - 由於2019年的計畫,有很多大項目,我們不需要太專注在workshop本身,而是專注在希望透過這次的會議,探索如何把這些大項目,依照使用者的使用脈絡( scenarios),合時合地的提供給他們。

Design Sprint 2.0

當確認參與人員只能勉強擠出一天半的時間之後,就開始思考該怎麼調整,做了一堆功課,再加上經過前輩指導之後,發現竟然已經有Design Sprint 2.0,而且還是經原作者認證過的改良版。Design Sprint 2.0大致上,是把原來5天的workshop,縮短成了4天,並只要求決策者(Decider)僅需全程參加前兩天。終於,在參考Design Sprint 2.0的議程,再加上自己的一些調整,總算排出了以下的規劃。

啟動會議(Kick off meeting)

  • 設定目標(Set a long-term goal)
  • 列舉衝刺問題(List sprint questions)
  • 製作使用者體驗地圖(Make a map)

在正式workshop開始前,舉辦一場一個小時的啟動會議,除了大致說明workshop的議程之為,主要著重在上面列出的三個活動。

因為,2019年計畫開發的幾個大項目,大致上,可以劃成兩個主要的使用者旅程(customer journey),再加上,團隊對於2019年的計畫,並沒有太多的不確定性,很多討論都在一瞬間就完成了,因此,大家決定這次workshop,直接鎖定兩個經驗地圖,希望在第二天workshop結束時,能夠完成兩套分鏡腳本(storyboard)。製作完使用者體驗地圖之後,就開始分配回家作業。

回家作業是要求每個人,針對三個預設的主題(例如:A與B比較,像是同系列產品不同型號的比較,或是不同付費方案的比較等),分別找出三個以上,最喜歡的設計,接著把這些設計列印出來,帶到workshop當天使用。

Workshop 第一天下午

  • 地圖檢視與分工(Review the maps and divide)
  • 設計範例分享(Lightning demo)
  • 第一個地圖的設計草稿(4-steps sketching)
  • 第二個地圖的設計草稿(4-steps sketching)

Workshop第一天從下午一點開始,第一件事就是面對面再檢視一次在啟動會議時,畫出來的兩個使用者體驗地圖。接著,每個地圖各有兩個重點需要設計,因此,分工的方式就是每個人分別從兩個地圖中,各挑一個重點來設計。舉例來說,我們有甲、乙兩個地圖,而甲有A、B兩個重點,乙則有C、D兩個重點,我就挑了『甲 A』跟『乙 D』作為我下午的設計目標。

分工完之後,就是設計範例分享(Lightning demo),每個人利用自己的電腦,把自己前幾天找的設計範例分享給大家,分享的同時,也要簡單說明一下,這個設計範例有什麼值得我們學習的。

在Design Sprint 2.0裏,建議在workshop當天,排25分鐘的時間,讓大家獨自安靜的上網找範例,然而,根據這次的經驗,我很慶幸我請大家在啟動會議後、workshop開始前的這段時間,自己找時間去搜尋範例。因為,我們有三個預設的主題,還希望大家每個主題至少找三個範例,我自己就花了週五一整個下午與週六晚上兩個小時,25分鐘真的會不夠用。我可以理解Design Sprint 2.0會這樣建議是因為,很多人都不會乖乖做回家作業,很幸運地,我的參與人員,最後只有一位沒有作回家作業。

另一個值得慶幸的決定是請大家把回家作業事先印出來,Design Sprint本來的做法是讓主持人(Facilitator),把大家分享的範例,重點式的畫在白板上,然而,我發現,要在有限的時間(每個範例只有2分鐘分享時間)之內,要把範例重點畫出來,真的不是一般人辦得到的。

Image for post
Image for post
這是Design Sprint本來期待的結果(圖片來源 sprintstories
Image for post
Image for post
這是我在設計範例分享之後的休息時間,把大家印出來的回家作業貼在白板上。

設計範例分享之後,就是兩個75分鐘的設計草圖,本來規劃每個75分鐘之中,前20分鐘是抄寫目標、衝刺問題與設計方案發想,接著,花10分鐘進行Crazy 8s,最後,45分鐘繪製設計方案。結果,沒有人要抄目標與衝刺問題,因為會議室很小,一眼就看到我寫在白板上的字了,每個人都直接開始畫設計方案,結果,我連Crazy 8s都省略了。

Image for post
Image for post
目標與衝刺問題就在後方的白板上,一抬頭就看得到。

Workshop 第二天上午

  • 設計草圖提案(Solution presentation)
  • 熱圖投票(Heat map vote)
  • 最高級投票(Super vote)

第一天workshop結束時,我請每個人把設計草圖交給我,本來打算晚上回到飯店之後,自己先看過一輪,以便在隔天一早的設計草圖提案時,可以幫大家總結每一個設計草圖的重點,結果,我真是太天真了。即便前一天,我已經提醒了每個人,第二天的議程首先是,讓每個人安靜地觀看每一組設計圖,並默默地投下自己喜歡的部份,因此,設計草圖必須在沒有人解釋的情況下,還能讓觀看者理解,如果必要,可以加註文字說明。晚上在飯店看完設計草圖之後,除了我自己的,沒有一組設計看得懂!立刻改變計畫,讓每個設計者,自己解釋自己的設計,解釋完之後,才進行熱圖投票,省略書中的風向投票(Straw poll vote),然後,跳到最高級投票(Super vote)。

Design Sprint本來會這樣,主要的考量是希望讓所有的設計草圖都是匿名狀態,也就是希望避免參與者被『誰是草圖作者』而影響的專業判斷。但是,因為草圖實在太草,我只好賭這個團隊每個人都很專業,並不會為了討好某某人而故意偏向一方,好在,最後的結果證明我賭對了,被選出來的草圖並沒有因為是決策者畫的而被看中,也沒有因為我畫得比其他人好看而被偏好。

最高級投票,基本上就是決定哪些設計一定要被考量,並由決策者解釋為什麼,然後,大夥就開開心心去吃午飯了。

Workshop 第二天下午

  • 使用者流程(User flow)

本來,根據Design Sprint 2.0,下午的議程在使用者流程之後,就是要畫出完整的分鏡腳本,以便之後要設計介面原型(prototype)時,有個脈絡,然而,我們卻在使用者流程時,卡關了。

本來的計畫是,請決策者(首席工程師)與首席產品經理一起畫出幾個主要的資料庫效能調校流程,畢竟,這兩位都在資料庫效能管理這個領域,有超過25年的資歷了,想說應該可以輕易完成。沒想到,光討論要畫多細就卡住了,畫得太簡略,跟我們最初在啟動會議畫的體驗地圖沒有太大差異,畫得太細,又有千百種體驗分支,無法逐一列出,最後,只能勉勉強強畫出了兩個流程,就決定不在繼續進行分鏡腳本的繪製,直接利用這個面對面的機會,討論未來三、五年的規劃了。

Image for post
Image for post
首席產品經理在努力畫使用者流程(user flow)

心得總結

這是我第一次主持Design Sprint workshop,老實說,我給自己打了65分,針對workshop本身來說,很多議程都沒有達到原先預期的結果,甚至有些議程,進行到一半我就開始懷疑為什麼要做這個,反而結束的有點草率。但是,對於將要負責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的產出是否能解決你現在面臨的問題。

Workshop到現在,還剩下設計原型(prototyping)跟使用者測試(user testing),如果還有什麼心得,再繼續跟大家分享,如果你們有其他的心得想交流,也非常歡迎。

免責聲明:文章中有許多中文,都是我自己硬翻譯的,因為沒有看過Design Sprint的中文版,如果翻得不好,不要咒罵我。

James Liu

Written by

James Liu

Senior UX Designer @ Amazon

AAPD — As A Product Designer

AAPD 專注於分享數位產品設計的相關資訊,並且致力在平台上創造更多的交流與互動,我們關注UI設計、UX設計、設計師的個人成長、設計趨勢與產業動態等,希望透過這些知識的傳遞,能夠降低每位設計師成長的過程中所遇到的阻礙。歡迎來信投稿:aapdgo@gmail.com

James Liu

Written by

James Liu

Senior UX Designer @ Amazon

AAPD — As A Product Designer

AAPD 專注於分享數位產品設計的相關資訊,並且致力在平台上創造更多的交流與互動,我們關注UI設計、UX設計、設計師的個人成長、設計趨勢與產業動態等,希望透過這些知識的傳遞,能夠降低每位設計師成長的過程中所遇到的阻礙。歡迎來信投稿:aapdgo@gmail.com

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store