design-sprint-method_000

初探 Google 提出的設計敏捷方法(Design Sprint Method)

設計敏捷方法 (Design Sprint Method)是由 Google 提出,且於內部實踐並受到歡迎。它的概念基礎來自於其他已經在產業界應用的方法,例如敏捷開發(Agile)、設計思考(Design Thinking)與革新遊戲法(gamestorming)。這個方法試圖讓每個設計團隊都能輕易的導入,且能於 2~5 天內解決設計挑戰或測試設計原型。

本文介紹的內容整理於 Google 在 2015 年公開的電子工具書 – “Design Sprint Methods“,這本書簡述這個方法中的角色、功效、時間、工具與流程等項目,不過 Google 也指出他們的目的,並非要求大家一定得按表操課,而是鼓勵或激勵新創或任何規模公司的設計團隊,能發展出更有趣、多產且能適應的變通方法。好吧!廢話不多說,以下就讓大舌頭來導讀吧~

設計敏捷方法 初探

團隊成員

設計敏捷方法

Google 建議的團隊人數約 5~8 人,其中包含設計師、工程師、產品經理或相關領域專家(如圖中的團隊即有兩位設計師、一位工程師、一位原型設計師、一位 Sprint Master 與一位研究員)。若團隊人數超過這個建議值,可拆成數個較少人的團隊。並依組織或企業的目標,讓不同團隊面對相同或相異的挑戰。

對團隊的成員構成有初步認識後,我們暫不描述這套方法怎麼運作,而是介紹其中決定專案成敗的重要角色 – Sprint Master 之能力、職責與事項等。

誰是 Sprint Master?她/ 他要做什麼?

基本上,Sprint Master 就是整個團隊的領導者,他們的背景通常是 UX 研究員或設計師,且需要對設計流程、UX 方法論、策略、激勵指導團隊技巧與談判有深度的瞭解。他們最大的任務即是:1)定義設計的挑戰為何、2)建構團隊及 3)帶領團隊跑完整個流程。

“Sprint"是整個流程相當重要的名詞,它指的是解決一次設計挑戰的跌代流程,若要更深入了解可參考敏捷開發的文章

在進行 Sprint 的前中後,Sprint Master 都有不同的事情需要做,該花的時間也不太一樣,我們就由下圖來說明:

Design Sprint Method_02

Sprint 前

Sprint Master 在此時做的事情相當關鍵。首先,他必須定義好這次設計的挑戰為何?以及工作時程。再來,他必須建構團隊,並用 lightning talks 的方式向成員說明任務與使用者資料,並安排好後續測試的相關細節。另外,若能準備好環境,將會讓 Sprint 進行的更順暢,例如一張大桌子(facilitator’s desk)與討論的空間。

Sprint 中

在 Sprint 開始後,Sprint Master 將扮演促進者(facilitator)的角色,像是掌握時間或節奏、讓每個人都能參與、指派、給予方向、減少溝通摩擦、每日工作檢查、每日發出總結信件與鼓勵讚揚等。有時候議題可能會因為討論而有了新的方向,此時 Sprint Master 也必須快速做出決策,與統合大家的目標。

Sprint 後

當 Sprint 結束後,Sprint Master 須保持帶起來的熱情與衝勁繼續下一個計畫,並將這次 Sprint 的結果紀錄並分享給所有成員,並藉由此次的經驗讓下次的 Sprint 更好。

Sprint 前的準備事項

在開始 Sprint 前,Sprint Master 要設定或選擇好團隊將要面臨的挑戰為何。首先要簡單明確的呈述挑戰的目標,並告知該專注於哪個族群,下方舉個例子:

針對 4~7 歲孩童設計直覺的平板閱讀體驗,並在第四季推出。團隊需產出 mockup 及可點擊的 prototype 供測試。

Design Sprint Method_03

接著,召開一場與相關權益人的會議,Sprint Master 能從中判斷與學習是否選擇了對的挑戰目標,考量因素包含:1)訪談相關權益人、2)參考現有資料、 3)參考相關的使用者研究報告、4)分析近期相關設計與5)參考使用者案例。

準備好環境、設備與工具

Design Sprint Method_04

Sprint Master 需將任務時程表規劃好,同時選擇好要應用的方法,例如本書提供的或任何適合的方法。另外,安排一個大桌子,它能在整個 Sprint 過程中起了 “激勵討論" 的效用,當然還會需要一些簡單但有用的小工具,例如:剪刀、紙、膠帶、便利貼、投票貼紙、計時器或響鈴等。最後,若能貼心的準備小點心和咖啡的話,那就更完美了!

進行 Sprint 的流程

Design Sprint Method_05

跑一個 Sprint 有六個階段,類似 IDEO 提出的 Design Thinking 方法論,簡述如下:

1.釐清與了解(Understand)

使用者需求為何?商業需求為何?技術可行性?

2. 定義(Define)

決定關鍵的策略與應該關注於何者?

3. 發想(Diverge)

如何探索更多的想法?

4. 定案(Decide)

選擇目前最佳概念

5. 原型(Prototype)

做出概念的原型給使用者測試

6. 驗證(Validate)

向使用者、相關權益人與技術專家驗證概念

每個階段都含有許多實踐的方法,例如使用者訪談、競爭者分析或技術分析等。但我們不需要把所有的方法都用上,選擇適合且正確的即可,甚至根據經驗修改或調整過去的方法也行的!

STEP 1. 釐清與了解

360 度(全面) lightning talks

Design Sprint Method_06

這階段最重要的目的,就是提供不同的觀點來了解問題。這場會議應該包含下述的內容,此外顧名思義, lighting talks 就是要簡短扼要,不用花太多時間。

  1. 商業上的目標與判定是否成功的指標/5 分鐘
  2. 技術可行性與可能面臨的挑戰/5 分鐘
  3. 相關的使用者研究/5 分鐘

競爭者分析

研究 3-10 個相似的產品或服務,列出喜歡或不喜歡的點,這方法可讓我們更快進入狀況也能產生更多靈感。

使用者訪談

Design Sprint Method_08

我們都知道使用者會是最後使用與評價產品的人,所以這就是為什麼在 Sprint 開始前必須進行此步驟。如果是產品或服務已存在,我們可以問他們會如何使用,對他們的評價是如何;若是一項全新的產品,那我們要更專注於了解使用者覺得哪種解決方式比較好。

田野調查

有時候,訪談使用者不如直接走入他們的工作或操作的環境中來的有用,不但可以了解整個體驗脈絡,也可由中帶回最不失真的訪談。

相關權益人圖表

Design Sprint Method_09

醫療的相關權益人圖表

 

產品與服務的設計其實不只要關心使用者,所有相關權益人的需求都須考慮進來。我們可以嘗試在 30 分鐘內繪製出相關權益人圖表:

  1. 首先,陳列所有可能的權益人/10分鐘
  2. 將這些權益人分組/2 分鐘
  3. 決定哪些權益人是你在這次 Sprint 的設計對象
  4. 了解他們的需求

總結學到的資訊並嘗試提出想法

Design Sprint Method_10

在大家消化前述提到的資訊後,嘗試分享自己的洞見與初步的想法,將它表達於便利貼上。接著,將這些概念分組,並利用小貼紙投票來選出覺得好的概念。不過,最後選出的概念並非一定要往這個方向進行設計,團隊還是可在之後的步驟中,因學習、討論或發現而改變或優化。

 

STEP 2. 定義

使用者旅程(user journey)

Design Sprint Method_11

此我們可以透過展開使用者旅程,列出使用者從發現產品或服務、初次體驗、再使用及變的熟練的過程,來整理與分類概念,並定義之後設計的策略。

定義設計原則

Design Sprint Method_12

定義設計原則的方法很簡單,讓團隊列出認為或希望使用者怎麼描述產品或服務的形容詞,並選出其中最符合的三個。在 Sprint 結束後,你可以請使用者在體驗完 prototype 後說出三個詞彙來比較當初設定的設計原則目標。

想像發佈時的第一則社群訊息

Design Sprint Method_13

以 Twitter 來舉例,團隊可以想像當產品或服務首次推出時,你會怎麼發出一則貼文。這個方法可以協助團隊在少量文字下表達策略。

 

STEP 3. 發想

5 分鐘想 8 個概念

Design Sprint Method_12

這個概念來自於革新遊戲法(gamestorming),是一個暖身的練習方式。每個人都發一張紙,並對摺三次,展開後就有八個區域,接著花 5 分鐘在這八個區域上畫上一些想法。

5 分鐘畫出一個較好的概念

Design Sprint Method_13

接續上個練習,花 5 分鐘將比較喜歡的一個概念,較精細的畫在一張紙上。

5 分鐘畫出故事情境圖(storyboard)

Design Sprint Method_14

若概念較複雜不容易表達,我們就可以考慮用故事流程的方式陳述。團隊成員可選出使用者體驗的 “關鍵" 情境將它簡易的畫在分鏡中。(若您的團隊成員對這個方法感到陌生,可以告訴他們就像畫漫畫般)

 

STEP 4. 定案

靜默投票(Zen voting)

Design Sprint Method_17

在快速繪製概念後,大家可以將紙貼於板子上,全部看完後進行投票,但規定不能出聲。不能出聲的用意在於,避免因說服或說明後,而影響最初的個人想法。

團隊討論並決定以哪個概念做出原型

Design Sprint Method_18

團隊可以開始討論哪一項概念是最好的,並決定往下做出原型。此步驟不需要再進行概念發想的動作,例如草圖或探索。

思考帽(Thinking hats)

Design Sprint Method_19

如果團隊經驗較少或開始對意見有所偏頗或分歧,可以進行思考帽(Thinking hats)這個方法。讓每個成員扮演不同的角色(類似扣帽子的意思,如上圖),並模擬該角色的想法來表達觀點。這樣的做法的目的在於,讓討論更加多元全面。

上圖中的案例中就有五種角色,如:點子王、樂觀主義者、悲觀者、技術專家與使用者專家。

註:此方法是由 Edward De Bone 於 1980 提出,大家可參考這本書 – 六項思考帽

 

STEP 5. 原型

Design Sprint Method_20

原型大家應該都清楚知道,它能讓使用者足以真的感受到有這樣的產品或服務存在,這樣才能得到較不失真的回饋。同時,此書也建議可以花多一點時間在這個步驟中。

 

STEP 6. 驗證

使用者測試

透過原型進行使用者測試最大的目的,即是快速得到有價值的洞見。以下提供幾個簡單的問題供參考:

  • 使用者對原型喜歡與否,其原因為?
  • 他們覺得可如何改進?
  • 這個解決方案是否能滿足他們所有的需求?

相關權益人確認

概念要持續發展下去,關鍵的權益人掌握了決定權與資源,例如 CEO。所以他們的確認相當重要,是邁向成功的必要元素。

技術可行性確認

確認這個概念所需要的技術是否超過團隊的能力,邀請技術專家評估與討論,可讓後續發展更具可行度。

 

感想

有些設計師會將創意產出方法與設計方法論視為無用,相信創意的產出來自自我的黑箱(也就是靈感乍現)。事實上,在多元豐富的生活經驗、新事物的刺激、或傳化念頭下,設計師可能會突然產出獨特的創意或解決方法,也因此有些設計師會質疑具有流程、方法及工具的設計方法論,是否能有效的產出創意。

其實這樣的說法,大舌頭不否認,但重點應該視這些思維、流程、方法與工具為參考或激發的手段,畢竟團隊中具有精準洞悉與產出對的創意的人太少,而依靠個人創意所帶來的風險也非常大。因此,不需要對這些創意思考的模式與方法嗤之以鼻(例如設計思考、UX 流程等),這些方法嘗試著如何有效的讓 “每個 " 團隊進行準確、有效率與低風險的設計,也思考如何在實務上與其他不同專業的團隊合作。

不過,就如這本電子書 Google 提到的,他們也鼓勵各個組織可優化他們提出的方法流程。這點大舌頭認為非常重要,因為每個組織的文化、團隊、員工、設備等皆不同,如果硬要導入一種方法論,也許會造成水土不服而衍生更多問題。所以在對的方向上,應考量現況與團隊適應能力來調整,才有機會將這些思維與方法論帶來的效益發揮出來。最後,若各位讀者對此方法有任何想法,也歡迎在下方留言,大家一起來討論!

 

資料來源:Design Sprint Methods

衍伸學習書單:

本文章所屬設計大舌頭與作者所有,未經授權,不得轉載!如需轉載,煩請通知

如果你也喜歡我們的文章,請 Follow 我們的 Facebook 專頁,每天都會分享許多精選文章!

分享此文: