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

Renee S
Renee S
Mar 21, 2019 · 11 min read

這篇文章適合:正跟著公司跑 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 設計師在敏捷團隊最核心的因應之道!

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

Whoscall 設計師們的學習筆記

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

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