現任 Google UXE 告訴你：超少人知道的「既做 UX 也寫程式」實際工作內容、面試過程與暗黑心得(!?)
哈囉大家好，我是 Mimin，在 Google 擔任 UX engineer （ 使用者經驗工程師 ）。UX engineer 是正式存在但很少人聽過的職位（ 就算是 Google 內部也鮮為人知 ），網路上的相關資訊也不多。常常有人問我「所以 UX engineer 到底是啥？除了『既做 UX 也寫程式』，應該還有很多有趣的東西可以講吧？」
因此，這篇文章就來一探這些有趣的東西啦！在這篇文章裡，我會…
- 介紹 Google 的 UX engineer 職位
- 說明面試 Google 的 UX engineer 要具備什麼技能
- 聊一下個人的暗黑心得及常見問答
（ 當然，這篇文章全部都是我的個人意見，不代表任何 Google 官方立場。）
有沒有很期待呢！?
不過，在開始前，先讓我自己賣瓜一下：
我覺得我能當 UX Engineer 真是太幸福了！??
在成為 UX engineer 之前，我也是個平凡的 software engineer，待過小至十人的新創，也蹲過大至十萬人的跨國企業；做過後端，做過 web 前端，當然也做過全端——從決定顯示給使用者看的字的大小顏色，到去 AWS 看為什麼 ELB 會掉 request ，或是為什麼自己 compile 的 memcached 會造成 kernel panic，我都做過。但一直以來…
比起
調一下這個 linux 參數，就可以提升系統的 throughput
改一下這個資料結構，就可以在這個 node 多塞一個 worker
我更喜歡著手
先載入一半的 UI，然後加入 loading 動畫，使用者就會覺得這個 app 變快
改變一下選單的資訊架構，使用者就可以更快抵達目的地
這類的問題。
（ 噢，而且我從小到大都一直在做個人網站，資訊工程系的無聊作業我也都會額外做出不無聊的 GUI 來喔！）
因此，在我還是 software engineer 時，我也有考慮過是否要直接轉職當 UX designer。不過，因緣際會之下，我得知了 UX engineer 這職位，巧妙地結合我過去的軟體工程經驗及我對使用者經驗的興趣；上工之後，也很開心實際的工作內容就如預期地既好玩又有挑戰性。
真的是太棒了啊～～！
好啦，所以 UX Engineer 到底是什麼？
傳統上，軟體開發流程是「設計師弄好設計，交給工程師實作；工程師在實作的時候，設計師去做下一階段的設計」。這幾年來，大家發現這種開發流程不夠用：工程師和設計師雞同鴨講，沒有共通的語言；設計師不知道工程師的能力範圍到哪；工程師遇到問題需要設計師解決，但設計師已經忘記他兩個月前的決策過程； ^!%O*Q#&@ …
在職務分工明確的大企業下，這問題就更嚴重了。因此，這幾年來，會寫程式的設計師、或會做設計的工程師，因為擁有兩邊的技能，就成為炙手可熱的人才——
這就是 UX engineer：
As a UX Engineer, you’ll weave together strong design aesthetics with technical know-how.
我們身為 UX engineer ，既知道怎樣做好 UX，也知道正確的軟體工程原則。我們既講工程師語言，也講設計師語言。我們這一秒開 Sketch 拉 UI，下一秒就在 debug JavaScript timing issue；這一秒在想 prototype 的 user study 要怎麼進行，下一秒就在處理剛刻好的畫面裡莫名出現的橫向捲軸。
在 Google，UX engineer 根據實際上的職務內容，又分了兩種次職位（ 稱作「lens」），有：
- Design lens
- Eng lens （ 又稱 Front-end lens）
同時，也分各種平台，如 Web、iOS、Android、VR/AR。
平台的差別，各位讀者大概已經猜到了，因此以下就讓我來介紹 Eng lens 跟 Design lens 的差別囉。
在開始之前，請先看看這張圖（ 並忽略我潦草的筆跡 ? ）：
Design-Lens UX Engineer
Design-lens UX engineer 做的事情更接近 UX designer。只是 UX designer 用各種設計工具（ Sketch、Figma、… ）做設計，而 Design-lens UXE 寫程式來做設計。
具體來說，Design-lens UXE 寫程式製作 prototype，來解決其他設計媒介無法解決的產品設計問題。
例如，今天團隊想了一個新功能，然後發現…
- 它需要一個新的 API，且後端工程師要一個月才能弄出來
- …這功能聽起來很花後端工程師成本
- 那我們要先做 user study 了解這個功能帶給使用者的價值後，才能決定要不要花那個後端工程師成本
- 而且這功能很複雜；單純的「按到底」（ click-through，如 InVision 或 Adobe XD ）prototype 無法忠實呈現它帶給使用者的 mental load
- 可是我們沒有那個 API 的話，就沒辦法真的刻這個功能來做 user study
- （ 死結！️?♀️ ）
這個時候，Design-lens UXE 就派上用場了。他們會跟 researcher 討論，在沒有後端 API 的情況下，要怎麼寫程式做 prototype 才能達成高品質的 user study，驗證這個新功能的價值。
另外，Design-lens UXE 在要取得 stakeholder buy-in 時也會發揮用途。類似上面的例子，許多大公司的產品，只有用程式寫出來的 prototype 才能表達複雜的使用者互動及資訊架構的流動；stakeholder 們也必須親手試用這樣的 prototype 才能判斷新產品的價值。此時，就更能應證 IDEO 內部很有名的一句話：“ A prototype is worth a thousand meetings. ”
不管是哪種情況，Design-lens UXE 要寫的「程式」種類及規模五花八門：可能是一個全新的 app，也可能是修改現有的 app；可能是用前端的 framework 來模擬新的後端行為，也可能要自己開一個新的 Google App Engine 來實作完整的 tech stack。無論如何，只要能快速回答產品設計問題就好。
為了能快速回答產品設計問題，Design-lens UXE 也要能迅速釐清問題的本質，做出妥善的判斷。例如，或許某 user study 的 prototype，就算使用假資料，且忽略使用者網路不穩定的情況，依然可以達成 user study 的目的。總之，為了節省製作 prototype 所需的時間，Design-lens UXE 就會做些（ 合理的 ）偷吃步。
對了，Design-lens UXE 大多是編制在 UX team 裡面。看完上面的描述，應該不意外吧～
Eng-Lens UX Engineer
Eng-lens UXE 做的事情更接近 software engineer。不過，他們比一般的 software engineer 更了解 UX，可以決定一些 design spec 沒注意到的細節。（ 例如，UI 內的字串超過容器的大小時，決定是否將容器拓寬，或不拓寬而使用刪節號。）
Eng-lens UXE 又分為兩種：
- 做面對消費者的產品的 UX engineer：他們就跟 software engineer 一樣寫 production code，不過專注在 UI 方面，而非後端程式。
- 做內部的 GUI 工具的 UX engineer：因為內部工具的人力資源需求特性，用 UX engineer 可以以一擋十，減少 designer 跟 software engineer 溝通的額外成本。
不論是做面對消費者的產品，或做內部的 GUI 工具，因為 Eng-lens UXE 都會直接影響到上萬甚至上億人，所以他們比 Design-lens UXE 更注重 code review、testing、code quality 等等其他軟體工程原則。也因此，Eng-lens UXE 大多是編制在 engineering team 裡面。
整體來說，UX Engineer 的價值，是 Eng lens 和 Design lens 的聯集：我們的守備範圍廣闊，不論是 UX designer、software engineer、UX researcher、product manager 或是 program manager，我們都幫得上忙：我們透過 prototype 釐清產品設計問題；我們協助 UX researcher 執行高品質的 user study；我們讓 design team 知道 engineering team 的技術極限在哪，免得做出不切實際的設計；我們在 engineering team 有設計問題時，使用我們的直覺與訓練直接修改程式；另外，因為我們熟稔 UX 跟 engineering 兩邊，有我們出馬，program manager 覺得時程超有保障。
對了，在 Google，這兩個 lens 並非涇渭分明；如果有 UX engineer 想要換 lens，不需要任何人資的程序，只要主管自行確認即可。（ 像我四個月前才剛從 Eng lens 換成 Design lens 喔！）
那…想成為 UX Engineer 要注意什麼呢？
基本功
這份工作在 Google 依然算是 engineering 職位。我們還是期待 UX engineer 有基本的資料結構與演算法概念（ 例如，知道為什麼 O(n^2) 比 O(2^n) 好，知道什麼時候 Set 比 Array 好 ）。當然，我們也期待 UX engineer 熟悉職位要求的平台（ Web、iOS、Android、VR/AR ）的底層特性，而不受制於特定的 framework。
不過，我們不要求 UX engineer 手刻艱難的資料結構或演算法（ 例如紅黑樹 ）。（ 但我個人覺得要會解 invert binary tree，畢竟…在做 UI 的時候常常需要用到各種 data transformation。）
去除了艱澀的資料結構跟演算法，相對來說，我們希望應徵者有足夠的 UX 知識，例如 usability evaluation heuristics 啦，design process 啦；以及有相當水準的設計思維，能分辨不同設計的優劣取捨。
我適合當 UX Engineer 嗎？
如果你目前是 front-end software engineer，然後你對「為什麼這個畫面加個『載入中』的動畫，我感覺載入速度就變快了？」「為什麼這個動畫跟那個動畫長度都是 200ms，但那個動畫好像速度比較快？」「為什麼這個東西要放這裡不放那裡？」有興趣，那麼你很適合來挑戰當 UX engineer！
如果你目前是會寫程式的 UX designer，然後你對「這程式這樣寫跟那樣寫的效果一樣，可是那樣寫的話我三個月後還看得懂我在寫什麼欸！」「有人說想要使用我這段程式，我來試試看怎樣把它包裝得讓別人也可以輕鬆使用！」「我想要把我的設計接上 production data 來看看遇到各種 edge case 時會出什麼情況！」有興趣，那麼你也很適合來挑戰當 UX engineer！
雖然有些人會覺得只有獨角獸才能當 UX engineer，但我覺得，如果你是 T 形人才，橫的是 design & technology，直的是 software engineering know-how，就已經非常符合 UX engineer 所要的特質了。
面試流程
Eng lens 和 Design lens 面試的重點有些微的差距（ 例如，Eng lens 可能會多問到 production best practice ），但流程跟關卡一樣。
- 跟 recruiter 電話聊聊，確認要投哪個平台跟哪個 lens
- 跟 UX engineer 電話面試，考 UX 也考寫程式
- 回家作業：給你一個 mockup，請你刻 UI 出來
- Onsite
- 幸運拿到 offer 之後，就跟一般 Google 面試流程一樣囉
這邊特別提一下回家作業跟 onsite 的部分：
電話面試通過了以後，就要做回家作業，題目大多是給你 mock 圖檔要你刻出 UI 。因此，你的任務除了刻 UI 以外，還要自行決定所有的互動設計細節。作業期限一週，交作業時需要提供原始程式碼；根據平台不同，也會要你提供成品的 hosting URL、APK、或操作影片…等等。另外也要提供說明文件。
Onsite 總共有四到五關（ 每種關卡的順序及數量不定 ）：
- UX concepts：考你的 UX 知識。這關通常由 designer 擔任面試官；偶爾也會遇到 researcher 擔任面試官。
- UX engineering knowledge：考你的平台所需的實作知識。這關由 UX engineer 擔任面試官。
- General coding ability：安安你有聽過刷題嗎？大概是介於 easy 到 medium 之間。這關通常由 software engineer 擔任面試官。
如果面試 Senior 以上，就會和面試 software engineer 職位一樣考 system design。
此外 onsite 時也會問回家作業相關的問題，設計或工程方面都會問。
平衡報導：UX Engineer 的陰暗(?)面
當然啦，這職位也不是絕無麻煩事。偶爾也會發生讓我們心累的事情…
我的 PM、PgM、designer、researcher、software engineer 不知道怎麼「使用」 UX engineer :(。
我的 designer/researcher 沒找我就把設計做完，user study 計畫都擬好了才叫我來趕快照著設計做 prototype，可是那個設計有超多 real-world bug…
我的 org 只有我一個 UX engineer，沒有別人可以一起共甘苦。
是的，就算是 Google 內部也不是每個人都聽過 UX engineer，第一次遇到 UX engineer 的人也不一定能立即理解怎樣和 UX engineer 合作最有效率。在這種情況，雖然可以勉勵自己，說我的團隊得到一個別人沒有的資源超棒棒，但…大多時候還是很阿雜。這種時候，只能想辦法努力找到團隊需要 UX engineer 超能力的地方，並積極貢獻，讓 designer/researcher/engineer 覺得有我這位 UX engineer 真是以一擋十，再口耳相傳，讓大家知道 UX engineer 的價值。
我的主管跟 UX engineer 職位不熟，不知道怎樣幫我打考績。
很多 UX engineer 的主管是 software engineering 的 TL/M ，或非 UX engineer 出身的 UX manager。他們比較熟悉 software engineer 或 designer/researcher 的考績項目及流程，而不太了解準確評斷 UX engineer 考績的方式（ 這邊指，要怎樣分辨是否超過 job ladder 設下的標準期望 ）。
這種時候要請主管去聯絡一些資深（ 這邊指 Staff 以上 ）的 UX engineer，討論在這個團隊內要怎麼衡量 UX engineer 績效。
跟我合作的 software engineer 的 UX 知識好像比我強；跟我合作的 designer 的實作能力感覺比我厲害。我懷疑我坐在會議室只能玩白板筆喝 LaCroix。
這在 Google 超常見的。我還遇過 UX researcher 本來也是線上這些大公司的 software engineer 又跑去念認知心理學，取得學位以後來 Google 當 UX researcher，該同事的實作能力依然一流。
Imposter syndrome is real，請相信自己在團隊合作內，絕對有「交給我做，事半功倍」的特殊能力喔。
其他不盡完美的事情
- Google 的 UX engineer 缺非常少。除了灣區、紐約、西雅圖以外，屈指可數。
- 承上，台灣 Google 從來沒有且現在也沒有任何 UX engineer 缺。（ 咦～台灣 Google 有 UX 嗎？軟體外商在台灣的辦公室有全職的 UX 職位嗎？）
- UX engineer 要參加的 meeting 超多。我們要參加 UX team 的 design critique，提出設計跟工程方面的建議；也要參加 engineering team 的 technical design meeting，確認設計師想要做的東西刻得出來；還要參加雙方的 sprint planning ，確定沒有意外發生。雖然 meeting 很多，但也只有去了，才能確保我們能把實作時間花在刀口上。
其他關於 UX Engineer 的 FAQ
UX engineer 的職務需求當然不是 Google 才有。很多注重 UI/UX 的大公司也有類似職位，可能稱作 Design Technologist、Creative Technologist、Design Developer、或 UI Engineer/Developer。當然，職務內容不盡相同。
我沒有同地區同 level 的 software engineer 的薪水的資料所以無法表示意見。此外，把 offer 談高最快的方式是拿到 competing offer。
有但很少。正職缺都那麼少了 ?♂️
Job ladder 有定義到非常高的 job level，所以我覺得發展應該很好。
此時，身為跨領域的好處又出來了，因為只要跟 UX 相關，或跟 front-end engineering（ Web、iOS、Android、VR/AR ）相關的外部課程，都會認定成與職務相關，所以都補助不少喔（ 請詳閱官方公開說明書 ）！
除了官方說法以外，UX engineer 們每年都會開 1.5 次 conference：年中有一週的 UX engineer 專屬 conference，年末則跟著 Google UX conference 有自己的議程。我們會邀 Google 內外 UX 人士「教新的 prototype 技巧」「教新的 library、tool、framework 用法」「教你怎樣做職涯規劃」以及其他超～有趣的題目。
那麼，這次關於 UX engineer 的介紹，就到此告一段落囉～希望這篇文章讓大家更了解這個職位；也希望對 UX engineer 有興趣的人可以成功轉職 ? ！
延伸閱讀：