告別 Jr. UX Designer 的 10 個小習慣（上）
有一件事在現今的產業中不一定正確，那就是頭銜能被掛上「資深」(Senior)，並不等於一個設計師工作年資夠久、年紀夠大。而是這位設計師能思考多深入、對專案能不能提出策略、對團隊有多少影響力、能不能幫使用者/公司解決問題。
我第一份工作是在顧問業當 UX Consultant，當時團隊的年紀幾乎都是三十以下的年輕設計師；而接下來到 Inhouse 後，發現自己雖然年近三十卻但都是團隊中年紀最年輕的 UX designer，也沒想到在工作後的第2.5年被升成 Senior UX Designer。
事實證明了年資不一定是讓自己從 Junior 變成 Senior 主要指標，制度上有些公司在設計師的升遷計畫中，明確列出設計師的職等，以及每次升等時可以參考的指標，例如：解決問題能力、主動學習能力、專案領導能力等等。設計師跟主管可以每半年到一年評估這對時間內設計師的成長。
撇開制度層面，回過頭來，在設計師自我成長的路途上，到底有什麼盲點是自己看不到的、有什麼該打破的設計慣性，應該才是大家想知道的。此系列文章會以我個人的成長經歷出發，分享我從剛入行的時當 UIUX 與 UX Researcher 到後來專注於 UX 技能的轉變。
此系列的（上篇）文章會將焦點放在設計實作的習慣；（下篇）會延伸到團隊合作跟團隊影響力，（番外篇）會分享如何使用工具追蹤自己的成長。
關於本文 UX 的領域定義：
UX 設計師的職能很容易因為：團隊組成（組織健全/一人設計師）或
產品性質（創新/迭代）不同，需要專注在工作上的能力也不同。
所以在文章的一開始，想來訂定義此篇想論述的對象為 Inhouse/Consultancy的 UX designer
而非 UIUX designer 或 Product designer
關於作者的 UX 背景：
第一份工作在顧問公司擔任 UX Consultant 身兼 UX Research 與 UIUX Design
第二份是在 Inhouse 的產品研發團隊擔任裝置原生系統設計與導航軟體的 UX Designer
第三份則是在 E-commerce 擔任 Senior UX Designer + UX Researcher
(1) 是否在 Review 設計時仍關注 UI
慣性行為會影響一個人的決策模式。還記得剛入行的我 (UIUX 設計師) 第一個專案是做一個專案的 UI + 動畫，也讓我養成對 Pixel perfect 跟 Motion 品質的刁鑽，以至於在我剛變成 UX 設計師時，每次 review design 的時候總是把焦點放在：這個介面也太醜了吧、為什麼沒有置中、這個圖片去背沒去好、這個動畫怎麼這麼卡，什麼都看不順眼。
雖然每一種回饋都可以讓產品變更好，但如果把焦點分在 UI 上，就很容易錯失改善 UX 的機會。許多 UX designer 都是從 UIUX designer 升上來，但兩者需要關注的職能其實很不同。UIUX designer 跟 UX designer 相比，需要花更多心力在視覺上，也更需要了解如何實際打造產品，如何跟 Front-end 工程師合作；而 UX designer 需要從零到一規劃產品功能，理解人在使用數位產品的行為與需求、提供內容策略、符合商業價值、並規劃功能背後的邏輯，需要稍微理解偏技術面的知識才能與 Back-end 工程師合作討論。
所以成為 UX designer 後，在 Design Crit 或 review 專案的時候，要記得！任何直接用眼睛看出來的「視覺」問題都不該是 UX 首要關注的問題；UX 關注的議題，應該是這個功能怎麼用？背後的邏輯是什麼？與使用者的 use case 合不合理？要怎麼協助工程師 break down 這個功能。
能一邊畫 UX flow 一邊做到 High-fidelity 的 UX 可能會讓公司覺得應徵到你是撿到寶，但在團隊合作上是一個大大的致命傷。因為那樣不僅讓 UI 設計師失去了想像空間，也會讓不理解設計的其他團隊的人，分不清楚 UI/UX 的職能區別。
UX 設計師必須解放自己的潔癖，放下對 UI 的控制欲，就可以把更多精力放在 UX、技術或 Business 策略上。
(2) 是否太常以刪掉既有功能取代迭代
根據怪奇事務所的分享：「一個橫跨心理學、工程學及公共政策的跨科際研究團隊發現無論哪個專業領域，在遇到新問題時大多會率先想到『一定是少了什麼』而不是『好像多了什麼』。而且像這樣遇到問題只想著要加料，沒想到砍掉或許會更好的直覺式思維，長期下來會形成一種肌肉記憶條件反射，使人們更難意識到其他解決問題的可能性 — 換句話說，就是產生思考盲區。」
然而這個現象在設計界恰恰相反。我的推測，原因之一是現代設計提倡簡約設計；之二，也有可能因為產業現象，因為業主太愛加東加西，而造就設計師在「設計思考」的時很習慣質疑存在的意義，甚至有一種設計流派就叫做「減法設計」。然而這樣長期下也來會形成一種肌肉記，讓設計師總是想刪掉他認為多餘的元件、功能。
在我還是很菜的時候，經手過的前幾個案子，不少的更動都是在把甲方客戶亂放一通的按鈕跟重複出現的功能入口刪光光。其實刪沒有不好，但「刪除」是否有解決客戶/使用者的問題？更慘的是，有時候刪掉一個小元件，馬上發現整個功能崩壞、錯誤百出。
當有按下「Delete」鍵的衝動時，應該要先退一步，想想根本問題是什麼？問一下經手過專案的人為什麼曾經有這樣的決策？除了刪掉還有什麼解決方法？「增加新功能」跟「刪除舊功能」都是最簡單的解法，是人類最直覺（跟設計思考的反直覺）的肌肉反應，是不是還有更高明的解決方法呢？
(3) 是否常不小心拿使用者來驗證自己的想法
這點對新手設計師/研究員來說真的不太容易，不讓自己的主觀意識凌駕於客觀發現之上。不管是在設計案跟研究案中，當想從使用者身上想得到回饋或任何 insight 時，如果設計師/研究員先射箭再畫靶，在還沒拿到真正使用者回饋時，直接有了「前設」，很容易讓整個案子充滿 Bias 而失敗，例如：
- 在訪談前已經有了前設，認為使用者一定有這樣的問題，而讓該問題主導了研究方向（但可能使用者根本沒有這個問題）。
- 在訪談或 U-testing 前就認為可能有這樣的問題，而用了引導式訪談
老實說，在我的設計生涯中也參與過一些讓人扼腕的研究案，尤其是在乙方顧問業，很容易遇到甲方客戶想拿研究案來驗證自己的假設。但他們殊不知研究的主要目的並不是拿來讓他們心中疑問被使用者驗證，而是要探索使用者真正的行為。但當研究結果不符客戶期待時，研究案就不太容易被採納。所以在乙方公司做設計研究時，更要把精力放在如何跟甲方交代研究如何進行，也需要給客戶心理建設：他們的前設有可能是錯的，甚至可以邀請乙方來 Shadowing 訪談/使用者研究，讓使用者為自己發聲。
(4) 是否不畫 User Flow 直接做 Prototype
Great UX isn’t a product of your imagination. It’s a product of extensive research, careful planning, repeated testing, and many trips to the drawing board. So how do you make sure this process is as efficient as possible? How can you be certain you’re designing with your users in mind? — Nick Meyer
設計師常常太依賴視覺思考，而失去抽象思考的能力。舉例來說，由於Figma 太方便做 Prototype，常常讓設計師有了初步的 Wireframes 後很直覺地開始做 Prototype，因為相較於 User flow 或工程圖，Prototype 「看起來」比較好讓人理解功能怎麼運行。但如果不畫 User flow，很多細節是無法被思考到的：
- 設計師就失去了幫使用者沙盤推演的機會，我們可能會因此遺漏了一些需要引導使用者走過的 Edge case 或 Error status。
- 失去「根據使用者行為」而調整「Backend 技術」的機會。因為有一些功能甚至無法用畫面表達的，例如：裝置與手機的藍芽連線流程，在這個流程有時候根本沒有相對應 UI 產生。如果在畫面上沒有特別描述，工程師就得自己摸索，可能也無法針對個別的使用情境做優化了。
畫 User flow 的另一個好處是，畫出來的 Flow 上的每條路徑跟每個判斷式都可以清楚列出決策理由，有可能是測試競品的發現、也可能是遵循 Native OS 的行為、也有可能是使用者需求，記錄下這些都可以讓團隊裡的其他成員更了解功能細節。
(5) 是否為了解省時間不思考功能背後的邏輯
為什麼大家常常說 UX 設計師必須要有很好得邏輯思考能力？不僅是畫 Flow 時要靠邏輯畫判斷式；也因為設計產品時要考量的因素很多（使用者 User、商業 Business、技術 Technical），必須有一套邏輯來梳理雜亂的需求。邏輯不是考試沒有一定的對錯，他是個工具可以讓我們透過判斷一個事件是否會發生的「是與否」來審視，如果這個因素發生，會影響什麼；這個因素不會發生，又會影響什麼；設計上會有幾種解法，而我們要不要提供這種解法，哪一個是最好的解法呢？
設計前與設計時不妨要思考：
- 使用者面向：使用者在目前遇到的困難是什麼？使用者解決的問題是什麼/哪些，哪些並不是使用者的需求？
- 商業面向：為什麼這個功能會這樣設計，當初設計的時候有什麼商業考量嗎？
- 技術面向：為什麼是這個解法，是因為技術有什麼限制嗎？上一代的技術限制可以克服嗎？怎麼克服？
例如，我曾經做過「搜尋引擎」的重新設計，整個設計過程只碰到一兩個簡單的元件（Search bar, Search Result Drop-down, Result page），原本以為這個專案可以很快的結案，但開始設計才發現一個好的搜尋引擎的體驗必須從引擎本身的邏輯開始設計，透過邏輯讓使用者能從大量的資訊裡面搜尋到最相關的解答。因次，後來居然從搜尋引擎的規格書開始看起，看這個引擎的閱讀能力、運算邏輯以及資料在公司內部系統的內架構。最後才終於完成了整個引擎的體驗改造。
當 UX 設計師就是這樣一直不斷的向使用者探索真相，然後不斷的向開發團隊同步目標。每一次多給自己一點要求，即便長了幾根白髮，都是改變習慣的契機。此篇文章分享設計實作的習慣，（下篇）會延伸到團隊合作跟團隊影響力，裡面探討的改變是更影響設計師變成 Senior 的關鍵指標，大家下次見啦。
