本篇主題要提及的是 UX in Agile 之下衍生的問題與生存 >>
不少初入 Agile 開發模式的 UX Designer 常問: UX 在 Agile 中要怎麼做?運作方式是什麼?
- 團隊要用 Agile,但自己發現 UX Work 在流程上配合得不順利
- UX in Agile 似乎必須要學
- 即使讀了 UX in Agile 的(夢幻)教學文,在操作上仍然礙於現實問題🤕
UX Work
UX Designer / Researcher 被賦予的任務從出生以來一直都是「 使用者中心 」、「 為使用者發聲 」的代言人 👼。
而隸屬「 UX Work 」 的事情實在太多了,為了完整詮釋使用者中心代言人的角色,UX 使者們除了要研究新東西、研究舊東西,還有無止境的測試、協助迭代的設計等。
而造成在 Agile 難以執行的原因不外乎為:要執行的項目太多、時間不夠。
UX in Agile 的困難
會讓設計師產生障礙的,常常是因為 Sprint 裡面的 Task 太大,大到無法在時間內完成 UX Work。
單純就測試與設計迭代這兩種任務,對設計師來說不難掌握,即便不是 Agile 體系,頻繁的修改本來就是設計師日常,設計師大可在上午測試這個小功能,下午再修改另一個小功能。產出物基本上都可以隨著每個 Sprint 持續支援。
可是說到產出物,如果產出物是以使用者中心為出發的設計,那設計導向勢必要從 User Research 中得知。
但 Research 說到底,研究的細度與資訊獲取的精準性成正比,如果要將研究工作切分成數個小 Task 到 Sprint 中,那就得將研究模板固定化。但做研究是一條漫長的觀察與分析,即使切割成多個 Sprints ,也沒有太大的實質意義,因為研究類型的產出物,要馬就是一個確定的結論,不然就是被視為新發現的論點,而在抵達這種結果之前,研究都只是資料彙整而已。
設計原則給予的協助
使用者研究的歷史已經有一段時間了,有很多設計原則已經能讓大家在設計的候拿來做參考。
當在設計比較簡單任務的時候,Designer 可以直接遵照一些現有的規範來執行,也就是以歷史研究來做為參考的遵循設計,這樣的好處是在工作上就可以跳過不少基本研究。只要是擁有一些經驗的 Designer ,想要在一開始就順利將 UX Work 導入 Agile 中並不是難事,因為他只要會發現問題,再找到對應的答案就好了。
表面的研究,產出也是表面的
但除了基本設計原則可以提供的設計方法外,每個產品本身還是有很多自己的特質,例如特殊的功能、特定的使用族群、產品被使用的環境等。假使設計在涉及產品核心的部分時,依舊是參考其他產品作為範本,那這個產品最多最多也只會和其他產品一樣可以用,想要更好甚至打敗其他對手的產品是不可能的。
平平一樣的產品,人家的使用者都已經有相當的忠誠度了,為什麼還要跳槽來用你的產品呢?
沒有類似的競品?......那不做使用者研究的話,怎麼知道自己的產品是會有人買單的?
🤔
小心假迭代送給你的是真成本
從 Agile 的精髓來看,密集交付的行為與慢究型的研究任務大相徑庭。不過 UX Designer 是可以先分析幾樣數據後,照這幾樣數據來設計一個「可能會是真的的版本 」然後開始測試,待獲得更完整的數據後,再設計一個更適合使用者的「 認真版 」來構成快速測試與迭代( Lean UX )。
但假如「可能會是真的的版本 」已經下去跑正式開發了,那「 認真版 」的迭代就只是一個假議題。
這就像印刷一樣,在發印以前你想怎麼改字體、怎麼換材質都不是問題,但等到印刷廠把你的 DM 印出來以後,你才想要修改內容重印一次。這樣能算是迭代嗎 🤔?
成功的 UX in Agile
成功的 UX in Agile 關鍵在於:
- 每個 Sprint 的任務真的很小,小到有足夠的時間來完整 UX Work。例如:找出最能吸引使用者的首頁圖、研究畫面上某個互動設計的影響。
- 每個 Sprint 任務太大的話,團隊就得有多位設計師,也就是人手夠多。這樣才能把時間不足的地方用人力來補上,產出相同的水準。
- 穩定的團隊成員在合作上已經擁有默契,能在團隊中落實無礙的協作。
基於以上,要在短短的 Sprint 中完成任務是一定可行的。
UX 該怎麼於不適合的環境下生存?
當然團隊的開發模式、任務大小、時程限制往往不是自己可以決定的。
所以初入一個團隊時,你可以先去「 研究團隊的工作 」,然後思考怎麼運用自己的專業來提供自己的價值( 既然研究是你點的技能樹,那就好好用它,先研究怎麼讓自己可以融入環境 )。
「 所有的辦法都是從溝通中找到 」
每個公司的狀況都不一樣,這些不同取決於產品目的、現實的阻礙、團隊協調度、成本考量等因素。所以無論遇到什麼,最直接取得答案的方法就是去了解大家的協作方式,詢問產品管理者的訴求。
如果自己的工作上發生了障礙,就說出來,提出你的想法與大家討論,不然等到木已成舟時才發現質量未符,就會被認為是你的問題了。
而且你的障礙很可能也是別人的障礙,大家都在等待找出解決的辦法。
當使用者中心並不是主要任務的時候
UX 使者感覺得出來的 👼
上一段提到的「 現實阻礙、團隊協調度、成本考量 」就是一種非常寫實的開發狀況,有時候公司/客戶想要的產品和你所認為的產品其實不一樣。這樣的狀況在 Agile 中更能強烈感受到。
有的公司想要的 UX Designer 其實是為公司自己設計的設計師,追求的只是一個「 可以用的產品 」或「 Stakeholder 想要的產品 」。所以當這種情況發生時,你要滿足的其實不是使用者而是公司。
下面是我一個 UX in Agile 的經驗分享,它的產生只是因為適用於當時的環境。
記得我之前參與過一個 Agile 開發。在當時的團隊裡,「 讓每個階段擁有一點可用的東西 」是最重要的,也就是說絕對使用者中心的設計,在該公司其實並不是首要目標。因此在當時我並沒有把龐大的研究體系搬出來,取而代之的是採用適合團隊的做法,把工作目標訂立為:讓每個 Sprint 的任務是有效益的。
我將當時的工作內容為:
- 快速確認——從不同角色 ( 無論是使用者、顧客、或 Stakeholder )的 Story Mapping 上確認 Task 的目標。
- 遵循設計——用基本設計原則直接優化那些顯著的問題。
- 平行支援——協助開發團隊解決當前實作上發生的問題。
- 產品測試——協助測試產品,搜集問題。
在以上的狹縫中,若還能有其他時間(基本上是沒有),我才會著手適宜的研究方法。
開發模式各有各的好
但跑 Agile 的門檻非常高,重心著重在順利協作。為了順利協作,整個團隊裡的人都必須要思緒清晰經驗豐富,除了真的大神給予正確的方向外,老闆也必須給予絕對的信任,不去干涉團隊。在這樣的前提之下,能「 成功跑完 」Agile 並有效產出的真的少之又少。
開發模式各有各的好,選擇適合團隊現況的開發模式才是讓產品可能成功的基底之一。
如果為了快速產出而犧牲掉使用者研究的話,這樣的過程本身就不是使用者中心的設計了。
— 無所事事巷口觀察者