UX 設計師在敏捷團隊的因應之道

這篇文章適合:正跟著公司跑 Scrum 敏捷開發法,卻一直在流程裡載浮載沉的 UX 設計師

去年年底有幸受到 Agile Tour Hsinchu 2018 的邀請,跟活動參與者們分享了 UX 設計師在敏捷團隊裡的工作心得。在經歷一個充電長假後,我決定在這邊把演講內容做一個重新梳理,讓更多人可以針對這個主題進行交流 :)

如果你的團隊也在跑 Scrum,身為設計師的你是否也曾疑惑,這麼緊湊的衝刺裡,我們是不是只能執行短時間內能夠見到成效的任務?我們要如何真確地聽到用戶的聲音?怎麼做比較長期的設計規劃?怎麼驗證設計方案?

要討論設計流程怎麼在敏捷框架中運行,首先要先釐清手上的設計任務究竟是哪一類任務?

優化、維護型任務

如果你負責的是一個趨於成熟的產品,接到的需求可能會來自於產品上線後的小型用戶回饋、A/B Testing 觀測結果、小規模的產品策略變動… 等。這類的需求大部分不會對產品的主要功能造成大變動、解法也很明確,衍生出來的任務我先姑且稱之為優化、維護型任務

如果我們是開一家麵包店的話,優化、維護型任務可能會長這樣:

  • 有客服反映說麵包蓬鬆度不夠,我們可能就去調整一下發酵時間
  • 我們發現 60%的顧客都覺得我們杯子蛋糕上的奶油太多,我們就把奶油量減少
  • 我們想要增加品牌印象,所以我們在每個蛋糕上都印上我們的 logo
Photo by Kate Remmer on Unsplash

以我們 Whoscall 實際案例來說,優化、維護型任務就會像:來電封鎖失敗時需提供彈窗協助用戶、離線資料庫更新完成後需顯示更新筆數資訊… 等。

這類的任務通常不會改變主要功能,比如說蛋糕還是蛋糕、麵包還是麵包,雖然蛋糕、麵包上面可能會有一些微調跟修改,但我們不會再去開發新的使用情境、也不需要把主功能打掉重練。

這樣大小的任務,設計量大部分都可以規劃在一個 sprint 之內,跟團隊一起跑 Scrum 就相對容易了。只要提前一個 sprint 開始跑規劃設計,就可以在下個 sprint 直接進開發了。

易用性測試

易用性測試也屬於比較容易排進 Scrum 流程裡的用戶研究。若是要測試的功能實作上相對簡單,就有可能等功能開發出來後,再找用戶來測試。但如果是實作上比較複雜的功能,就可以在設計方案剛出來的時候,製作 Mockup 及早找用戶來確認設計的可用性,避免團隊在開發資源上的浪費。

中長期規劃型任務

那如果是碰到需要較長時間去思考作法的任務要怎麼辦?這類任務通常方向需求很明確,但是解法還沒有定義,所以需要比一個 sprint 更長的時間去做勾勒細節。

這類任務可能是基於原有功能上的衍生、可能是為舊問題找新解法… 等,我先姑且稱之為中長期規劃型任務

如果沿用剛剛麵包店的例子,中長期規劃型任務就會像是:

  • 我們原味杯子蛋糕大受歡迎,所以我們要趁勢研發水果味杯子蛋糕
  • 有人反映麵包的口味不夠有層次感,但是要有層次感可能有幾種不同的作法,所以我們就要試試看哪一種作法比較適合
  • 我們想要拓展年輕女性客群,所以要來試試以前沒做過的蛋糕裝飾

以現實中的案例來說,就有可能像:我們需要一個讓用戶感覺更簡單的 onboarding 流程,但我們還沒明確定義哪幾個步驟需要優化、要怎麼優化。

因為需要的設計時間比較長,所以最直觀的做法,就是硬生生把設計時間拉長 (但這個做法有很多衍生問題需要注意,接下來會慢慢提到)。

PM 可能好幾個 sprint 之前就來找設計師,討論他的需求。通常設計師就會先做一個整體的初步規劃,然後開始拆分任務、逐個執行。當然,逐個執行的過程中,也會不斷地回到一開始的初步規劃去漸漸完善它。

出於設計師熱愛整體性的天性,很多時候我們會偏好在有一個完整結論時 (通常是幾個 sprint 後),再開始跟團隊討論。這種情況下,其他職能的成員在設計前期就無從得知設計師做了什麼坑給他。

如果硬要把中長期任務套到 sprint 時程裡,其實也不是不可行。但常碰到的情況是,因為表定 review 的時候設計還沒最終定案,所以設計師在開會的時候講出 A、B、C 可能性,最後卻在要交付給開發的那一刻決定做 D 方案。

個人認為給予設計師充分的時間、用更全觀的角度去規劃設計,在很多時候還是必要的。因此碰到這種情況,可能的解法就是讓設計師跟團隊合作更加緊密,以非正式討論的方式多多探測團隊想法。同時,溝通的有效性也會變成了設計師的責任,確保其他職能的成員不會因為忙於其他任務,而無法深入參與設計討論。(這點比想像中的困難很多,但如果你的設計步調無法配合 sprint 時程的時候,就只能在別的方面多下功夫了)

探索型任務

那如果任務開始包含一些探索性質,方向、解法也更加未知時該怎麼辦?碰到這種探索型任務,你可能會發現前述的流程開始變得越來越不可行。這時候我們就會需要其他職能的成員放下手邊工作,一起認真投入討論、共同找到方向。

再回到我們開麵包店的這個情境,探索型任務就會像是:

  • 我們想往訂購量較大的派對、節慶市場邁進,所以我們需要找到杯子蛋糕以外的派對商品
  • 我們發現顧客普遍喜歡新鮮感,所以我們要開始發展一些新的麵包種類
  • 最近草莓批發價很好,老闆想知道我們有沒有機會乘勢推出一些草莓產品

探索型用戶調研

探索型任務有兩種開始的方式:

  1. 先深入研究用戶需求、行為,再依照證據規劃產品
  2. 先利用一些已知假設生成 prototype ,再利用 prototype 去驗證/修改假設,進而優化產品

如果是選擇從 1 開始,很多時候你的團隊會從探索型用戶調研著手,以確定團隊瞭解真正的問題,並提供足夠的線索去制定方向。這時候探索型用戶調研就會出現在規劃設計的前期。和中長期規劃型任務一樣,密切地與團隊溝通會是很重要的一環。最理想的是讓其他職能的成員一起參與調研過程,可以大大拉近產品團隊和用戶的距離。

如果是選擇從 2 開始,則你很有可能會從以下的探索方式著手:

探索方法一:精實 UX

當碰到有試錯空間的探索型任務時,可以試著把找方向變成一個團體活動,讓這不再是一個 PM、設計師自己關著門想破腦袋的流程。

如果大家熟悉精實 UX,就會知道精實秉持著敏捷的精神,提出了這個學習輪迴:設定假設 -> 建立原型 -> 快速實驗 -> 得到回饋。在建立原型的階段,團隊會產出最小可行產品 MVP,一旦產出可以運作的 prototype,會趕快推給使用者做測試,以收集回饋。

在曾經跑過的專案裡,我們嘗試了大家不分職能地一起跑了這四個步驟。我們一起定義用戶族群、訪談公司內部 stakeholder、完成價值主張畫布、 brainstorming 解法、 排序點子、生出 prototype 上線測試、最後一起做用戶訪談收集回饋…等等。

很可惜的是,當時雖然大家一起做了設定假設跟建立原型的步驟,但是在建立原型的過程中,我們忘了首要任務是要建立 MVP - 而 MVP 是為了驗證假設、收集回饋用的,並不是正式產品的規格。一旦大家開始專注在生產,自然而然就很容易忘記假設是假設,也很容易忘記要設計之後的實驗、並思考如何收集回饋。

個人覺得這應該是跑精實十分常見的一個問題。在很多公司,MVP 會變成說服高層 “產品可以更快產出” 的一個手段,然後大家做完 MVP 就忘記後面步驟了,甚至在MVP 出去後,馬上就開始規劃全新功能了。

所以,如果要跑這個流程,請務必記得:要實驗!要收回饋!經過幾輪迭代,我們才會正式進入開發的循環。

除了 MVP 不小心變成了正式產品的規格、大家忘了要實驗/收回饋以外,另一個跑精實常見的問題是:大家忘了MVP是會隨著不同的回饋及發現而調整方向的。但如果我們在完成第一版假設後,就忘了它也是要隨著新方向不斷調整,我們就不會回去更新我們的假設,自然而然就沒有第二次的學習迴路,也就越走越偏了。

這樣聽起來,把這個流程拉太長也不是什麼好事,我們可能會忘記應有的四個步驟,在流程裡打滾太久也很容易忘記初衷。如果想要更快速地得到初步結論,Design Sprint 是另一個可行的方法。

探索方法二:Design Sprint

Google Venture 有制定了另一套五天的流程叫 Design Sprint。相信這個名詞大家都已經聽到很熟悉,我就不再多花篇幅介紹了,有興趣的人可以參考:

Design Sprint 會把要做的事非常細地一步一步列出來,然後也是遵循設定假設 -> 建立原型 -> 快速實驗 -> 得到回饋這個學習輪迴,讓精實的實作性大大增加。

當然,Design Sprint 也有它適合跟不適合的專案。這裏順帶講一下 Design Sprint 的優缺點。

好處是:

  • 能增進不同職能間的凝聚力及共識
  • 時間被限制在五天,所以討論效率會被逼著開掛
  • 非常適合大家在還沒有共識時使用,能快速幫團隊找到一個方向

壞處是:

  • 只有一天研究用戶,其實很難有效驗證用戶是不是真的有這個需求,或是用戶需求會沒辦法深挖
  • 如果是非常複雜的議題,事前又沒有做足功課,過程中就容易腦補成分過多,到一定程度就會跟現實脫離、流程卡住無法繼續
  • 想 idea 的時間太短,導致 idea 無法深入,所以 idea 在 design sprint 結束後還是很難落地
  • 沒有決策者在時,基本上就是白跑!(然後決策者都很忙)

Design Sprint 能夠快速地給團隊一個方向,但要到可以實作的階段,通常還要經歷多次的迭代。評估完自己專案的實際狀況到底適不適合 Design Sprint,才能善用這個流程達到最大效益。

總而言之

不同的設計任務,在敏捷裡跑的流程也不一樣,所以並沒有哪一個是所謂 “最好的” 流程。

結論

先將任務分類

不同設計任務適合不同流程跑法。如果沒有萬用的流程公式,我們能做的第一件事,就是在接到任務時,先將任務分類:是維護型任務?還是需要花時間探索的任務?再回去看看什麼流程比較適合。

只有 “比較好” 的流程,不一定有 “絕對符合” 的流程

另外想要提一件事,其實選流程就像買鍋子,各種鍋子會有不同的特性:

  • 不鏽鋼鍋耐用,但重量重、需小心防鏽
  • 鋁鍋重量輕、便宜,但易氧化、怕酸
  • 不沾鍋省油、易清洗,但容易有刮痕、壽命短

每種鍋子的特質不一定是可以正反比較的,你的煮菜習慣可能比較適合不沾鍋,但你又有預算限制,所以其實鋁鍋比較適合。流程也是一樣,你不一定有 100% 絕對符合的流程,所以你只能多嘗試、多做實驗,才能找到 “比較適合” 的流程。

工具、方法需要被靈活運用,方法論也需要被客製化

找到 “比較適合” 的流程後,要記得所有工具、方法都是活的,需要被靈活運用。精實 UX 裡會做的 Persona、功能假說表… 或是 Design Sprint 裡提到的示意圖、閃電型示範… 等,都是我們工具庫裡可以個別運用的資源。工具、方法都需要被客製化成最適合我們的樣子。至於怎麼客製化,也是需要實驗跟經驗,所以不要怕去嘗試不同的工具、方法。

最重要的還是成員心態

最後最後,個人認為最重要的還是成員的心態。方法只是方法、工具只是工具,團隊成員的大量互動才是確保專案沒有走偏的關鍵。重視團隊協作、講求小批量快速交付、把握每次實驗機會、能夠定期地審視優化… 等,才是 UX 設計師在敏捷團隊最核心的因應之道!

如果你覺得這篇文章對你有幫助,請給拍拍手給我們一點鼓勵!你的支持是我們寫出更多好文章的動力喔 :)

--

--

如果我們沒有在搶零食,我們就是在學習的路上 😋

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