敏捷開發講求高效產出的文化，UX設計的流程和資源被壓縮，沒有足夠的時間，挖掘問題，探索解方
source: GIPHY
對敏捷開發有經驗的人，會知道團隊需要在特定的時間(大多數是兩週為一個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發生的機率也會隨之提高。
雖然我沒有太多這樣的經驗(慶幸自己待過的公司都對設計還蠻認可)，但我知道有些公司在資源有限的狀況下，常常會是專案經理製作設計流程圖或是市場行銷部門人員進行產品用戶訪談，在產品初期發展階段或許可行，但絕非長久之計。
/政府網站營運交流平台授權轉載/
原文作者：Hsuan
原文出處medium：UX theatre 是什麼？或許你、我都曾經參與“演出”