UI/UX 設計師的現實面— 打造團隊體驗
本文章是濃縮我之前在 UX cube 的演講「UI/UX 設計師的現實面」的部份內容，適合剛工作一到兩年，對工作感到迷惘的人們。
在正文開始前，想問大家一個問題：
有多少設計師真的依照以下這個設計流程進行產品開發的？
大家夢想中的設計流程大概是長這樣，一開始我們先研究需求、定義問題、同理使用者、打造概念設計、收集回饋、最後出版上線。
這是我們理想的烏托邦式設計樂園，但真的是這樣嗎？
完美的設計流程只存在在教科書中
在業界工作每一秒鐘都是成本，很多時候完美的設計流程並不存在於任何一家公司， 打造跟優化不同，若是在優化階段非得要走完完整的設計流程，反而會增加團隊的負擔，沒有一定完美的流程。
不要當團隊中的英雄
我們為什麼如此執著於流程，我們是不是把自己當作這個團隊的英雄人物，彷彿要按照我們說的做世界才會和平？
若是設計師將自己當作團隊內的英雄人物，因為我們（照理來說）最懂使用者體驗，像是前面看到的圖，把 UX 放在中央點，我們就會忘記自己在團隊的任務，體驗不是由一個人去搭建的，而是需要 依靠整個團隊的合作。
這裡有一篇非常棒的文章我想推薦給大家：
The great balloon of User Experience: from UX to Product Design
以及文中提到的 UX London 2018 中 Paul Addams 精彩的演講：
The End of Navel Gazing
這兩篇文章其實都在溝通一件很重要的資訊：
This is important: user experience is the outcome of the work of many people, the product of a product or a service, not a job description.
當設計師將自己放在中心點時，就會造成一個迷思，彷彿所有產品的運行都應該要繞著完成好的 ”UX” ，但其實我們做的各種事情都是為了去建立一個我們有足夠信心的產品去市場驗證，搭配著策略與市場規模與成本考量，平衡出一個最佳的流程，然後不斷迭代驗證再迭代，創造好的體驗是讓產品營運順利的手段之一，而適當的設計流程則是更間接卻關鍵的手段。
在 Paul Addams 的演講中，他多次提到設計師不該一直盯著所謂的 UX 中心點，因為在真實的業界中，你身為一個設計師要打交道的絕對不會只有設計：
“All these things matter a great deal, and UX is not in the center”
同時在 Julie Zhuo 的 The making of a manager 該書也提到：一個好的設計團隊的目標，應該要跟公司目標是有關聯的，就如同一個球隊的目標是為了贏球。
同理從團隊開始
在處理設計之前，先處理團隊內的體驗，如何交付、拆解 PM 的需求，如何溝通協調，用什麼角度切入可以讓事情更加順暢，你必須把團隊當作你的使用者，同理他們、找出讓他們的痛點，讓他們更願意與你合作打造產品。
體驗是從裡也到外的，從團隊內的產品開發體驗到對外交付給使用者的體驗，我們溝通順便吵個架，開發中的你讓我好做我也不讓你難做，過程中大家各司其職，負責公司目標的PM、操心使用者的設計師、維護產品機能的工程師、把關產品品質的QA，缺一不可。
公司開發的產品和服務其實都是公司自身組織架構、溝通與工作方式的反映。
- 康威定律 Conway’s law -
Don’t be a brilliant a-hole.
相信很多設計師一開始對於這個職業的夢想是要成為所謂的 Star Designer – 像是 Tony Stark 那樣才華洋溢、聰明過人的人才，我在早期的職業想像中也曾經希望自己是個超級設計師，可以打造超級產品出來，這個目標是好的，但仔細想想，如果你的團隊中有像是 Tony Stark 這樣個性的人（不管是什麼職能），你可能會覺得人生很難熬，這樣的人雖然擁有很棒的才華，但同時可能也是一個自我主張很強烈、獨斷獨行的人，的確這樣的人也許會交付很棒的貢獻，但同時他也會讓整個團隊的節奏非常不順暢，這是一個非常不利於團隊合作的事。
比起 Star Designer ，在團隊中更需要的是有辦法促進團隊節奏、打造團隊共識，跟團隊一起前進的人，而不是只有你一個人衝在前頭，然後毫無理由地要求別人跟上，適時地調整自己的的方法與方式，去了解團隊的問題點，並且在溝通上進行解決，才可能提高你打造出超級產品的的可能性，目前業界中我們看到的方法論與設計流程，你需要自己判斷哪些適用哪些不適用，而不是照單全收，然後逼迫你的團隊非得要照著你的方式做事。
等等，這意味著我們不需要去學習、嘗試正統的方法論嗎？
在推動團隊前，你需要打好基底
雖然我在前文提到了完美的流程不存在以及團隊合作的重要性，但這不代表當團隊的作法有誤時，你就得乖乖低頭遵守。
正統的方法論與設計工具，是你的專業底蘊，當你了解的夠多，操作經驗夠多，你才能更有效地去利用這些方法論跟工具，讓你的產品團隊做出更正確的決策同時擁有更高的效率。
但永遠記得體驗不是一個人可以打造的，體驗是需要依靠一個團隊去建立的。
建立你的團隊影響力
引導團隊去打造超級產品，除了設計師自己清楚了解自己在哪個階段的設計流程外，你同時也該傳遞這樣的價值給你的團隊，不是說服或是要嘴贏別人，你更需要做的是讓團隊信任你這個職能有其他更好的價值，找到你有志一同的隊友，打造屬於你們自己的團隊流程，並且不斷迭代優化，這時候你可能會有個疑問：我要如何建立我自己的團隊影響力？
有四個小建議可以分享給大家：
1. 了解你的產品團隊的體質
一個產品的開發中可能會有很多不同職能的角色的涉入，新創公司、老牌公司、顧問公司等等，每個公司的體系不同，也因應著有不同的開發體質，我會建議設計師先利用 RACI 模型，去對照你的專案流程裡不同的角色屬性，去決定你要如何發揮你的影響力。
2. 帶領產品團隊進入設計流程
在 Whoscall 裡，我們每個專案團隊都有相當高的自主性，這時候你需要去影響團隊成員去理解你的看法與脈絡，舉例而言，我們會非常鼓勵專案團隊成員跟我們一起去了解研究脈絡與用戶洞見，但當時我們遇到了一個難題：團隊成員非常有興趣了解使用者測試，但是他們沒有時間可以參與。
我們當時使用了線上直播的方式，讓 PM、開發、QA 在進行自己的工作之餘，同時也可以線上觀看使用者進行任務的狀況，這樣的方法達到了很好的效果（感謝當時我們很聰明的研究員 Chelsy Hsieh 想出來），團隊成員在底下暴風留言，各種洞見與討論在線上非常及時地出現，同時也達到我們想要產生的影響力。
3. 展示你的設計原型，持續創造溝通
IDEO 有一句很有名的名言：「一個原型勝過一千個會議。」
打造 Prototype 除了是為了設計互動、轉場方式外，也是一個很好的方法讓你的團隊了解你心目中的產品長什麼樣，以 Whoscall 為例，我們在打造 Prototype 的時機點往往在很早期的階段（例如需求確定後，但不確定要用哪種解法），我們會打造一些概念式的 Prototype 分享給團隊成員收集回饋，並且不斷持續迭代更新， 並且評估時程、對象、保真度、軟體上手度等等，去決定我們的 Prototype 應該是怎樣的，詳細的評估概念可以參考 Designing Products People Love 這本書。
有時候 一千個原型 不是為了讓你做出 很炫的互動，而是為了不斷與工程師討論研究。
4. 最後，在失敗經驗中不斷學習
我曾經做過一個專案，花了很多時間去研究、打造原型、提出設計假設、產出視覺，但最後乏人問津，這是誰的錯呢？是哪個決策出了問題嗎？
當我回顧這個專案時，我發現我們的團隊都非常優秀、大家都懷抱熱情並且願意貢獻，我們就像是很好的球隊卻輸了這一場球賽。所謂的影響力，並不是在誰出錯的時候出來指責，意外總會發生，你要學會下次如何避免，以我個人的失敗經驗為例，雖然專案不成功，但我累積了研究能力跟專案規劃、甚至是推動、影響團隊的能力，一次的失敗沒有關係，只要你能從失敗中學習到未來的技能。
影響力並不是魔法念個咒語就會成真，你需要深入了解團隊特性，針對團隊的流程與痛點，提出可以改善、幫助團隊的方法。
感謝大家閱讀這篇文章，如果覺得不錯請幫我拍手👏👏👏👏👏👏👏
同時也感謝當時邀請我去演講的 UX cube :)
