UX theatre 是什麼？或許你、我都曾經參與“演出”
在事事倡導以”使用者為中心”的年代，有多少時間，其實使用者的聲音是消失的？
不知道大家是否有跟我相似的經驗：
參加設計工作坊，期許發想出“以使用者為中心”的產品想法，但過程中卻沒有真正的用戶輸入，有的是團隊自行想像的用戶人物誌(persona)，依據這些“假設”，想出了數十個想法，滿心歡喜準備把想法落實在設計稿上…
這是我當時在第一份UX工作中所經歷到的狀況。
而這正是UX theatre的症狀之一 ：套用設計思考(design thinking)的方法學，但過程中，真實使用者的聲音卻是消失的。
在事事倡導以“使用者為中心”的年代，大多數的公司都會提到在產品設計過程中，是秉持這樣的信念去執行的，但大家是否有想過，UX theatre其實正在悄悄地上演中?
什麼是UX theatre?
這個概念是由加拿大UX設計師Tanya Snookn所提出的，描述在設計過程中，團隊應用許多 “以人為本” 設計思考的工具和方法，但卻沒有考量真正用戶的想法，僅是將“使用者為中心”當作一個口號。
相信大家對於這個現象應該不陌生，或許多少都在工作中遇過，譬如做了真正的使用者調研，但最後卻不被採用，因為跟公司決策方向不一致 🤨，又或是想做實際的用戶測試，公司卻說沒有這部分的預算😔….
Tanya把這個現象以UX theatre的概念傳達給大家，一語道破，UX領域在公司組織內，如何被曲解和誤用，導致產品無法傳遞真正的用戶價值，有的只是“以使用者為中心”的幻象。
UX theatre的各種“戲碼”
依據Tanya的圖表，UX theatre的症狀其實很容易觀察到，以下是她這邊列出的狀況，或許大家多少都有共鳴。
- 用戶調研過程中，團隊只使用“角色扮演”的方式，試圖了解用戶，完全沒有真實用戶的參與
- 決策層打著“以使用者為中心”的口號，卻沒有足夠的預算給到UX相關的團隊
- 以預算和時間有限為藉口，不邀請真實用戶，聆聽他們的想法
- 用猜想假設和自我意見，當作決策的主要考量
- 直到產品開發過程尾端，才有易用性的測試 (此時就算發現什麼，也為時已晚，單純只是一個“打勾勾”的過程)
- 工作坊是唯一的的研究方式
- 花費很多時間在“說”以用戶為中心的故事，而非花心力在產出以使用者為中心的成果
- 常常將“我們不需要測試，因為我們懂用戶”掛在嘴邊
- “我覺得 ” 替代“我看到 ” 和 “我聽到 ”
- 將設計思考與使用經驗設計劃上等號
- 團隊腦爆會議，缺少有經驗或受過訓練的facilitator協助討論
- 缺少用戶數據或是對數據有所質疑(因為與自己認知不同，認為“用戶不知道他們想要什麼”)
- 把“關起門”產出的想法，當作是最終定案
- “以用戶為主”的測試?!(user focused testing) (那為何不直接找真實用戶測試？)
- 用戶訪談，只問寬泛的問題，產出含糊的結果
- 讓沒有受過訓練或具備經驗的非設計人員，負責設計產出
在UX設計的工作經歷中，我自己大概經歷過70%的狀況，那時候還不知道自己正參與了UX theatre的“演出”，懞懂的認為這應該就是“以使用者為中心”的工作方式和流程😂。
而什麼導致了UX theatre?
[以下內容為參考 Tanya Snook, Jesse James Garrett & Tricia Wang這幾位作者在Fast Company的文章和我個人經驗，若有偏頗或遺漏，歡迎指教。]
UX定義廣泛，讓公司決策層或非相關領域的團隊對UX的認知有所不同，造成期待偏差
UX領域發展日新月異，UX設計師的定義一直再改變，不同產業對於設計師所需的技能和知識也都不同，其中之一的職責： “設計產品/服務與用戶的交互過程”，這一點相信是大家所認同的，但在這之外，像是質化&量化用戶研究、服務設計、產品文案、介面質量控管…等，都得觀看公司組織所需，並沒有一個非黑即白的標準化定義，這看似充滿發揮空間，但也開始讓UX設計團隊擔負許多以“使用者為中心”出發的工作內容，像是將現在業界很注重的“設計思考”與UX設計劃上等號。
“設計思考”(design thinking) 相信大家都不陌生，是一個能讓團隊“以人為本”來解決問題的方法，透過對人的需求出發，發想創新的解決方案，流程分為5個步驟(1)同理 (2)定義 (3) 發想 (4) 原型 (5)測試，並且不斷迭代的過程，但可以想像這樣的流程，所耗費的時間成本和資源，e.g., 前期背景調研、舉辦工作坊、真實用戶測試…等，這之中瑣碎煩雜的庶務事項，可以想像絕非是一、兩週就可以完善。
在這樣倡導運用設計思考，以使用者為中心的情況下，通常設計師都需要身兼許多角色，但往往造成人力資源不足，根據Nielsen Norman的調研，他們詢問了557位受訪者，調查在他們的組織內設計師/研究員/開發工程師的比例，其中50%是1位設計師搭配10位工程師的比例，從此可以看出，設計資源相對是緊繃的，更多新創公司甚至只有一人設計師，很多時候想要尋求外部資源時，像是聘請調研公司或是購買現成的報告，常常會得得到“預算不夠”或是“設計師應該可以自己包辦”的回應。
在這樣“要馬兒好，又要馬兒不吃草”的狀況下，形成兩難，沒有足夠資源奠基穩固的基礎，卻被公司期待所有的產出都需要以“使用者”為中心，漸漸導致尋求捷徑、犧牲掉耗時且可能看不到短期成效的步驟(但卻是重要的步驟，像是真實用戶測試)，漸漸造就UX theatre。
敏捷開發講求高效產出的文化，UX設計的流程和資源被壓縮，沒有足夠的時間，挖掘問題，探索解方
對敏捷開發有經驗的人，會知道團隊需要在特定的時間(大多數是兩週為一個sprint)，產出一定的成果，上線觀測，反覆迭代。雖然設計任務居多不會被列在sprint 的ticket中，但工程師要開發的項目，都需要根據設計稿來評估。
像是我的經驗，需要在sprint之前，就確定設計稿是被驗證過，得到大家(團隊和用戶)的認同。那還記得剛剛前面提到1:10的設計師和工程師比例嗎？在一個sprint中，若要讓每位工程師都有足夠工作量的情況，有時候會同時處理2~3個專案。時間再往前推算，這些專案都需要做前期研究、確認問題、設計發想、使用者測試、團隊和主管的評審，尤其是在定義問題階段時，往往是處理未知和各種不確定性，是最為耗時的….
但因為需要“敏捷”，導致時間和過程被壓縮，發現的“問題”，可能只是浮泛的症狀，而不是根本原因 ，結果一股腦鑽下，想方設法，最後更浪費時間和資源。
當然你可以說，這應該是設計師自己要依據經驗來提前規劃，而不是趕鴨子上架，被下個sprint的任務給追趕(殺)。但許多時候，產品年度計畫推出，在接下來實行的過程，各種不可預測的變化，伺機而動，有時候你年初做的設計概念，因為各種內、外部的因素，可能在三個月後就不可實行了。
當團隊期許一位UX設計師，可以像開發sprint一樣，在短期的時程，就可以從“未知”的問題到產出一個“以使用者為中心“的設計解方，UX theatre的各種劇碼可能就開始浮出檯面了….
在效率優先和時間被壓縮的狀況下，只能尋求最“有效率”的方法執行這些流程，讓設計產出看起來很“以使用者為中心“，抑或是將設計項目變成任務導向的產出，只專注在production level的交付(流程合理、介面美觀、標註完善)。
誤解”人人都是設計師”的真正含義
從Tanya的文章，提到這位Victor Papanek的美國作家在1970年代出版的《為真實世界而設計》(Design for the real world)提到“所有人都是設計師”這個概念 (All men are designers. All that we do, almost all the time, is design, for design is basic to all human activity.)。這個概念主要是傳達-人都具備以設計方式思考的能力，設計在思想層面上，是人類的基礎活動。在這樣的前提下，設計思考的方法就非常適用，引導我們以使用者為中心，去思考問題和尋求解方。
不過若公司團隊錯誤地理解這個概念，認為公司內人人都可以勝任設計工作，讓設計專業度被降低認可，認為其實非UX設計專業人士也可以執行，像是產品流程、wireframe產出或進行用戶訪談、主持工作坊…等，那UX theatre發生的機率也會隨之提高。
雖然我沒有太多這樣的經驗(慶幸自己待過的公司都對設計還蠻認可)，但我知道有些公司在資源有限的狀況下，常常會是專案經理製作設計流程圖或是市場行銷部門人員進行產品用戶訪談，在產品初期發展階段或許可行，但絕非長久之計。
那可以做些什麼，減少UX theatre發生的機會呢？
妥善分配時間，將設計項目”分級”規劃處理
前面有提到，UX theatre的發生原因，很大一部分是時間和資源不夠，我相信短期內不可能改變普遍公司設計師和工程師的比例，雖然規模較大的公司，UX領域劃分得比較細，較為專注，但多數的UX設計師都還是得“一肩扛”，但這也是讓UX更具挑戰和有趣的地方，不過做得開心，身體心理都要顧好，90% 在科技領域工作的產品設計師都認為自己有過勞(burnout)的症狀，可見事出必有因…
我自己的解法是將設計項目分為：長期 / 中期 / 短期，依據開發的緊迫程度，來分級處理。
- 長期：專注在年度的產品目標(OKR)，high-level的設計概念
這個階段，著重在清楚定義問題(透過數據或質性研究)、設計方案發想、產出設計概念; 若有資源，可先進行設計概念測試(衡量用戶對於這些新的想法，是否認同或覺得有需求，不聚焦在細節交互) - 中期：聚焦在未來的2~3個sprints，這個階段主要是分享設計概念給團隊(或stakeholders)、依據細節需求，更新設計稿、完善流程和製作原型，進行用戶易用性測試。
- 短期：針對目前sprint工程師所需的user story設計稿，完善細節流程(corner cases)、設計標註、所需圖檔…等交付。
這些不同分級的設計項目，會同時並存在我的工作時間，一星期的時間，20%短期，50%中期，30%長期。想當然，實際狀況並不是這麼清楚分明，有時候我可能整週都在跟工程師討論目前開發sprint的細節，這種狀況，我就需要“乾坤挪移”，自行安排時間。
那剛剛有提到，提前規劃，有可能到了實際工程師要開發的時間點，早已歷經各種改變，做好的設計稿早已不適用，這是有可能發生的….但我竟量確保在設計時，自行“腦補”各種可能性，也讓設計能夠做得更”模組化”，想法A不適用了，移掉就好，其他B, C, D, E….Z想法不受任何影響，不需要打掉重練。
在這樣分級處理的方法下，我可以因應項目性質，將需要優先執行的過程，安排進自己的工作時間，譬如“中期”的專案，我會優先安排易用性測試，“短期”的項目，我會放重心在那些unhappy path，確保用戶在各種“光怪陸離”的情境下，都能被妥善照料到。因應專案不同階段的需求，秉持以使用者為中心的原則，執行合適的任務，將得到的洞見應用在設計上。
省視設計思考方法學每個階段的目標，評估自身資源，找到最有效了解用戶的方法
產品設計過程，有很多流程步驟，業界或網路上也有各種資源，可以參考。但千萬不要被“流程”綁架，像是一定要訪談用戶才能發現問題，舉辦工作坊才能開始發想…等。這些設計思考的工具方法，都是在幫助團隊以用戶為中心思考，不是僵化不變的制式流程，更不是流於形式的打勾勾練習。
我自己是建議，可以運用目標導向的方式來省視每個設計思考的步驟和可以搭配的工具，像是“同理”階段，我們目標是要理解用戶使用行為和需求，接著評估自己的資源，哪些工具是適用的？譬如：若你的題目已經是主流議題，或許不需要用戶訪談，市場上就已經有很多現成的報告，足夠讓你理解用戶，這時候二手資料(desk research)或許就已夠用，這比起請公司同事扮演用戶，或是讓公司員工“下海” 實際執行用戶所要做的任務*，或許更能獲得洞見。
*Doordash要求員工每個月要執行一次送餐任務，期許員工培養同理心，但卻引來員工不滿
記下來，說出來！
最後這一個建議，其實有點老套，但卻是最容易忽略去執行的…
當觀察到團隊或公司組織中，出現了UX theatre(譬如：打著“以使用者為中心”的號召，但實際上卻沒有考量任何用戶的聲音或是只是讓它成為一個行銷賣點)，身為在產品研發過程中的“用戶”代言者，UX設計師要做的不僅是點出這些症狀，更需要擔起推廣UX核心精神和教育的責任，可以透過自己項目或是競業產品的案例分享，讓公司決策者和團隊了解，這些設計流程背後的意義，並且分析UX theatre對於產品發展過程中的弊端，讓大家對“以使用者為中心”有正確的了解，並且認同它的價值，進而思考是否需要再擴大資源，讓更多專精不同面向的UX領域工作者，加入團隊中，一同“施力”💪。
日新月異的時代，UX領域的工作者角色一直在更迭和擴展(UX、UI設計師、產品經理、研究員、內容策略、產品體驗文案…等)，所負責的工作領域內容也日漸多樣，但我相信不會改變的是引導團隊“以使用者為中心”思考和產出對用戶有價值的解決方案，讓“以使用者為中心”不只是流於形式的口號。
希望大家都不會有與UX theatre“聯手演出”的機會，可以扎扎實實的打造以"使用者為中心”的設計！
*以上內容居多是以UX 設計師觀點出發，若有偏頗或缺漏，歡迎指教(鞠躬)
這邊是UX theatre相關的文章，有興趣的人可以看看👀
