為什麼會出現這個角色?
傳統流程是設計師交付畫面、工程師照著實作,中間的落差就是交接問題(見「設計交接」)。互動、動畫、細節質感很難用靜態稿說清楚,設計工程師直接用程式把它做出來,省掉翻譯。
AI 讓這條路更寬。State of AI Design 2026 的 Craft 章節指出,50% 的受訪者已把 AI 產生的程式碼推上正式環境,但只有 20% 自認是設計工程師。換句話說,許多人在做設計工程的事,卻沒有這個頭銜,也不一定有對應的審查機制。
設計工程師實際怎麼工作?
設計工程師通常在設計系統的兩端移動:一端讀設計稿與 token,另一端寫元件與頁面。有了 Figma MCP 之類的工具,Claude Code 可以讀設計稿的版面與變數再產生元件,設計工程師的工作更偏向「定規則與驗收」:決定要重用哪些元件、檢查輸出是否貼近設計。
在正式環境這一端,關鍵是審查關卡。DoorDash 的設計師與工程師走同一套 GitHub PR 核准流程;Flux 則用 AI 風險評分做事後審查。這些做法都是公司自述,報告沒有提供退回率或事故數據。
對我有什麼影響?
如果你是設計師,這是一條現實存在的職涯路徑:uithings 引用 Built In 2026 的美國資料,平均底薪約 148,301 美元,範圍 83K 到 233K。這是二手整理的單一來源,實際薪資依地區與公司差異很大,且該指南同時在推廣 designengineer.xyz 的課程,讀的時候請當作有立場的來源。
如果你是主管或老闆,重點是別只看會不會寫程式,而是先決定審查關卡:誰核准設計師的 PR、出問題誰負責。這比職稱重要。
Vercel 的設計工程團隊(2024 年 3 月,uithings 列出 Rauno Freiberg、Jhey Tompkins、Henry Heffernan)被當作常見案例;DoorDash 的設計師必須通過與工程師相同的 GitHub PR 核准,並加了一道設計審查,由被標記的設計師核准 UI 變更。
優點是省去交接翻譯,互動與細節更貼近設計意圖;缺點是需要同時維持兩種技能,且組織必須另外設計程式碼審查關卡,否則品質風險落在不明確的人身上。