本篇主題要提及的是 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 並有效產出的真的少之又少。
開發模式各有各的好，選擇適合團隊現況的開發模式才是讓產品可能成功的基底之一。
如果為了快速產出而犧牲掉使用者研究的話，這樣的過程本身就不是使用者中心的設計了。
— 無所事事巷口觀察者
