一人設計師的求生指南
前言：一人設計就像是拓荒者
不知道大家現在的工作環境是「一人設計」還是有「設計團隊」呢？
我目前是在所屬的產品團隊中是一人設計，有趣的是，在我之前團隊並沒有 UI/UX 設計師這個角色，所以設計師如何跟其他角色建立關係，如何推動設計流程等等，可說是沒有任何前例可循，往好處說就是彈性非常大，有種「你就是規則的建立者」這樣的感覺。
更特別的一點，我們團隊沒有 PM。是的，你沒有看錯，沒有 PM，應該說 PM 的工作內容會平均分攤在每個團隊成員上。
我覺得一人設計就像是拓荒者，沒有前人踩出的路可走，就自己走出一條，反正走岔了主管會協助糾錯提點，所以就先照自己的意思走走看吧！先試再說！
秉持著這樣精神，我開始了身為一人設計的各種嘗試。（目前也還在各種嘗試中。）
以下分成三部分跟大家分享：
- 一是如何融入團隊，這是關於合作的部分
- 二是如何推動設計流程，是關於發揮專業的部分
- 最後是一人設計在整個團隊的定位，我自己的一些個人想法
那我們接著看下去吧！
1. 一人設計師要如何快速融入團隊？
主動跨出第一步，建立其他團隊成員與你的信任感
加入一個新團隊，不只是你要適應團隊，團隊也是要花時間適應你，但大家又有例行的工作項目要做，可能也沒這麼多時間理你，在這種時候就由我們主動踏出第一步建立橋樑。
舉例來說，目前我和團隊成員幾乎都是遠端上班，所以我們的日常很仰賴文字這種非同步溝通。
所以每當我接了新需求要和不同的工程師第一次合作時，我都會在 Slack 先傳一個簡單的訊息，像是：
「Hi 我是 Emma，是這次專案的 UI/UX 設計師。想請問我目前是用 Figma 做設計，那 Figma 做設計交付是 ok 的嗎？」
這個訊息一來是打招呼，二來是確定一下彼此的慣用工具有沒有需要調整的地方，因為我們公司並沒有硬性規定一定要用 Figma 、 Sketch 或其他設計工具，只要合作順暢都可以，所以提前確認合作方式是不是雙方能接受的。
再舉個例子，就像每個設計師有自己的做稿習慣一樣，每個工程師也有，所以在頭一兩次的設計交付時，我會跟他們用語音直接順過一次設計稿和設計說明，看看這樣的交付方式有沒有問題。對於不熟悉 Figma 的工程師也能趁機說明簡單操作和如何看數值。
通常這樣的一來一往間，你就可以稍微抓到這位工程師的個性和喜好的合作方式，對方多少也能從你的主動中了解到你是一位彈性、可溝通的設計師。
就算你是一人設計，建議也要與主管建立設計會議
這也是個經驗教訓，剛加入團隊時，常會參與各種不同的產品會議，但每個產品的開發階段不一樣，有的可能有時間多做一些前期調查，有的要搶時機快速做 A/B Test，會收到很多不同階段需求。
幾個禮拜後，我發現兩個不順的點：
- 一是我的主管好像掌握不住我的 loading 狀況，我覺得這是應該極力避免的事。
- 二是需求的優先順序的變動速度很快，我沒有一個好時機點確認，常是被告知 A 項目可以稍等，B 要先做，但我可能 A 正進行到一半，要中途轉換到其他項目，又耗費一些交接的時間。
所以我就跟主管提議，希望能有設計會議（就算會議上只有我和他兩個人 XD），會議上主要確定三件事：
1.本週要進行的設計項目
2. 項目的優先順序
3 . 何時交付
只要確定這三件事，就能掌握這週整體項目的輪廓，就不會出現你忙得要死的需求不是對方最急著想要的狀況。
在執行設計會議數週後也有跟主管聊到，因為每週都有設計會議，他也能清楚知道我目前的狀況，所以每週短短的 15–30 分鐘設計會議，能確保你和主管有在同一個共識上。
2. 一人設計師如何推動設計流程？
先了解團隊的運作模式
一開始加入團隊時很一頭熱，會有很多想法想嘗試的甜蜜期，我常常會跟主管說「我想做使用者研究」或「我想建立設計系統」等等，當然主管的回覆都是很正面的都可以去試試看。
但後來我就發現，不是每一個開發需求都一定要做使用者研究，也不是一次就能一蹴可幾做到大型公司等級的設計系統。
在走過幾次團隊習慣的開發流程後，開始意識到不是告訴對方「為了瞭解用戶我們應該要將使用者研究加入開發流程」，就硬加入一個流程，然後團隊就會運作起來，不是這樣的。
查理．蒙格說「如果你想要說服別人，要訴諸利益，而非訴諸理性。」
過去我會說「OOO 研究方法很棒，我們應該試試看」，但這句話對團隊其他人來說一點誘因都沒有，又要花時間，是無法驅動他人的。
這時我才了解到，我沒有思考到因地制宜，這個方式是不是適合現在的團隊，有沒有辦法真的幫助產品變得更好，我只關注在自己的設計活動本身。
於是我開始試著將問題重構：不是在團隊中推動設計流程，而是如何配合團隊現行的產品開發流程，將使用者體驗設計補入，讓產品變得更好。
為什麼是「配合團隊現行的產品開發流程」呢？因為對於團隊成員來說
再小的改動，都是成本。
都要再重新適應，所以在儘量不改動現在的流程，偷偷在一些合適的時機點插入一些設計活動，對一人設計來說會是更好的做法。
如何見縫插針的將使用者體驗補入
比如說在專案還有一點時間餘裕的情況下
- 第一步我就會跟主管說我想先做點「小調查」再進入設計發想，沒錯，用字上捨棄很高大上的「使用者研究」，而用「小調查」這樣的軟性的詞語，讓對方覺得你不是要花很多時間完成一個大篇幅的東西。
- 接著第二步會把我想要怎麼執行，要花多少時間，需要用到什麼資源一並跟主管說，比如說：
「我想找 3–5 個人做簡單訪談，從招募到訪談到結果分析大概需要 3–4 天，招募問卷我已經準備好了，只要請工程師幫我放上去就可以了，後續受測者聯絡我會來進行。大概 3、4 天後會將訪談結果跟大家分享。」
通常這樣的情況下，主管都會同意。
再舉一個例子，有一次針對一個需求我們想了A 和 B 兩種方向完全不一樣的解法，而不同解法在工程端的架構上會非常不同，所以選定一種解法後，後續如果要換另一種成本會很高。
但 A, B 解法各有優點，討論後遲遲無法下決定，所以我就提議這種時候就很適合做「簡單的易用性測試」，看看用戶真實回饋，而後續也因為用戶回饋得以選定方向。
最後是只要有訪談、易用性測試或問卷調查，結果分析都一定會貼在群組與團隊分享，一方面是其他成員或許也需要這些資訊，一方面慢慢讓這些「以使用者為中心」的成果多次出現在團隊成員眼前，讓他們在淺移默化下知道真實用戶回饋，並且這些回饋是真的對決策有幫助。
3. 沒有人有義務給你解答，你就是產品的推進者
如同最一開始背景所述，我們團隊沒有 PM，所以接到需求時，基本上我就會從很前期開始設想或是規劃。
剛進團隊遇到最大難題是，你接收到的第一手的目標都是很新鮮的，未經轉化的，沒有人會直接會給你設計規格，那要如何從理解抽象需求層層轉換到設計解法？
一開始我真的非常驚慌，那時的我很頻繁找主管討論，很想要直接從主管或其他的利害關係人身上得到一個直接的答案，告訴我應該要怎麼做。
後來我才了解沒有人有義務給你解答，而且我們做的很多事是沒有真正的「解答」的，大家反而期待你的發揮。
所以我也開始訓練自己如果目標是要影響最終關鍵指標，那要如何以終為始去拆指標，進行假說思考，然後去定義問題，找出解決方向。
你就是產品的推進者，雖然最終的決策權可能不在你身上，但你要有「今天如果是我，我會怎麼下決策」的氣魄跟團隊討論，有這樣的意識，在討論時就不單單只是羅列解法，而會把每個解法的優缺點，影響層面，和權衡後的建議做法是什麼一一跟團隊說明。
而不單單是把決定權交給別人，等著被動進行被交代的事項。
身為一人設計師，你不自己推著產品走，還指望誰呢？
結語：帶著一人設計的雙面刃開疆拓土吧！
我覺得一人設計師中，「彈性」一詞就是一個雙面刃，因為有彈性，所以可以融入整個開發團隊，可以參與每個需求的前期討論，可以知道哪裡是需要設計施力的地方。
但另一方面，也因為一人設計，會懷疑自己的設計決策，會不知道自己是否正在前進，但這些疑惑真的無法解決嗎？
在跟一些設計師朋友聊過後，他們給了我很多很好的建議，像是會懷疑決策就多找主管討論，了解多方看法，並學著留意決策後的結果，從結果回推決策是好是壞。
不知道自己是否正在前進，可以為自己設立短期目標，又或是向外挑戰更資深位置，都是檢視自己是否進步的方向。
不管是一人設計或是在體制完善的設計團隊裡，都一定會有各自的不得已，所以關鍵點不在你所處的環境，在你自身，如果你清楚知道「我在這階段想達成什麼目標？」「目前的環境能幫助我達到嗎？」，如果這兩個問題你都能自問自答的出來，那麼我相信不管在什麼環境，這些環境都會變成你前進的助力。
如果你現在也剛好是一人設計，這帶著這把雙面刃開疆拓土吧！
最後附上我的 IG: 設計女子艾瑪的學習之路
歡迎大家來跟我打個招呼，主要會在這邊分享各種設計知識與經驗！🙌
https://www.instagram.com/emma_uiuxdesign/
✨問題大力募集中✨
你也有想對話的創作者嗎？
2023 8/22 9pm 我會在Unblock學院邊聊文章邊回答來自學員的各種QA－關於設計研究、職場實況！
UIUX不是一條自己可以走完的路。它是一條私密又流動開敞的思緒漫遊，我們時而獨立、時而團體，但共同點是，我們都難以只靠自己突破困境。
於是，《設計快問快答》來了‼️
作為設計時代的專屬福利，Unblock每個月會驚喜邀請不同自媒體創作者舉辦Q&A快閃活動 — 我們會事先搜集任何想問此創作者的問題：關於文章、背景、求職方向與作品集建議等，只要在Unblock學院填上問題，就可以與喬治和創作者們一起進行各種觀點的抒發與討論。是一個認識不同領域的設計師並且近距離的互動、對談的好機會。
