UI/UX 設計師的英文履歷怎麼寫
更新於 2026-09-02
設計師的求職材料是兩份文件的分工：作品集證明手藝，履歷提供證據。履歷上每一行要回答三個問題：上線了沒、指標動了沒、範圍有沒有因為你的研究而改變。把履歷寫成作品集的目錄，兩份文件都會失職。
這個分工決定寫法。Personas、journey map、wireframe 是活動紀錄。一條合格的設計 bullet 動詞開頭、指名你負責的流程、以 [N] 收尾，例如 task completion 從 [N]% 升到 [N]%。本頁所有範例都是英文，因為外商履歷的成品語言是英文。數字一律留 [N]：面試時要守住那個數字的人是你。
以下依序：版面結構（以及為什麼設計師的履歷反而該是你最保守的一份文件）、三個層級的 summary、依職能分組的 bullet、改寫前後對照、技能取捨、ATS 關鍵字、常見錯誤，與每句主張會招來的追問。
這個職位的英文履歷，完成後長這樣
下面是一份虛構人物的完整範例，由產品的排版引擎渲染成真正的頁面，分數由同一套規則引擎現算——不是我們打上去的。缺的數字一律留 [N]，所以分數停在上限以下；那不是範例的缺陷，是產品的規則在示範。
Lucas Ferreira
Education
- Founded the faculty’s open user-testing club, which still puts [N] student projects a semester in front of real participants
- Won the undergraduate design prize for a wayfinding study of a metro station carrying [N] thousand passengers a day
Experience
- Redesigned account opening after [N] usability sessions, raising completion from [N]% to [N]% and cutting support contacts about the flow by [N]%
- Led the accessibility audit that fixed [N] WCAG failures before the app passed [N] million users
- Halved declined-limit calls to the contact centre by shipping the credit limit screen that explained the decision
- Designed checkout flows for [N] retail clients, with the largest recording a [N]% lift in mobile conversion after launch
- Introduced weekly user testing to the agency process, replacing stakeholder review as the primary design signal
- Delivered the design language for a [N] million-reais grocery client, adopted across its app, web and in-store screens
- Shipped the driver app’s pickup and drop-off screens as the startup’s first designer, from paper sketches to store release in one quarter
- Rebuilt the shipment-tracking screen around the two questions customers phoned about most, found by reading [N] weeks of support transcripts
- Cut handoff from a slide deck to one annotated Figma file carrying spacing and state notes, so the [N]-engineer team stopped rebuilding screens twice
Projects
- Created a free Figma kit for PIX payment flows downloaded [N] thousand times
Additional Information
版面結構與順序
單欄、標準標題、系統字型。這條規則對設計師最反直覺，也最重要。解析器讀不懂雙欄與自訂排版。看履歷的人會假設你懂得替媒介選擇形式，而履歷這個媒介的形式就是保守。把履歷排成海報，是拿可讀性去換對方根本收不到的風格。
作品集連結放在最上方的聯絡列：一條乾淨、可點的 URL。不用 QR code、不用縮網址、不放三個平台的連結；需要密碼就把密碼寫在旁邊。每多一個步驟就多一次流失，而流失的那個人不會告訴你。
- 1Summary
三句話：層級、產品領域、一個守得住的量化成果。這段決定對方要不要點開你的作品集。
- 2Experience
倒序。每段三到五條 bullet，指名你負責的流程、標明是否上線、以 [N] 成果收尾。
- 3Selected Projects（選用）
概念練習與 side project 放這裡，標明 concept。新鮮人可前移；寫法與工作經歷完全相同。
- 4Skills
工具、研究方法、交付規範三組。這是關鍵字對照表，只列答得出追問的。
- 5Education
設計學位或轉職課程一到兩行。工作三年以上放最後。
三個層級的 Summary 範例
Summary 的任務是替作品集贏得那一次點擊。三個層級各一例，數字留 [N] 由你自己填。
Product designer with [N] shipped features from a marketplace internship and a campus project serving [N] weekly users. Moderated usability tests I ran removed one launch-blocking flow issue before development began. Portfolio shows each project from brief to shipped screens at a single URL.
新鮮人的證據是一件真的上線、有人在用的東西，加上一次真的測試。最後一句預告作品集的結構，比列軟體清單有用。
Product designer with [N] years across fintech and marketplace products, owning flows from discovery research through shipped UI. Redesigns I led raised task completion by [N]% and cut support contact volume by [N]%. Most useful in the build phase: reviewing implementation with engineers and trading spec details against real constraints.
中生代要讓人看見完整所有權：從研究到上線。第三句講工作方式，也就是願意在工程限制裡交換細節。這正是面試會驗證的協作證據。
Senior product designer leading a [N]-designer group across two product areas and running the design system serving [N] teams. Research programs I set up changed roadmap direction twice in one year. Every case study in the portfolio ends the same way: what shipped, and what the metric did.
資深的證據是方向被改變：roadmap 因研究轉向、設計系統被多個團隊採用。最後一句同時立了標準：每個案例都用成果收尾。
依職能分組的 bullet 範例
設計 bullet 依職能分組。骨架不變：動詞、你負責的流程、方法、[N] 成果，或一個被改變的決策。
研究轉成決策
· Ran [N] moderated usability sessions on the checkout redesign, surfacing a mislabeled shipping step behind [N]% of drop-offs before a line of code was written.
· Turned [N] support tickets and session recordings into a ranked findings list; the top three findings cut two features from scope and saved [N] engineering days.
· Interviewed [N] first-time sellers in two markets, reframing onboarding from a form-length problem to a trust problem and rewriting the quarter’s design brief.
流程與資訊架構
· Redesigned plan selection from [N] screens to [N], raising task completion from [N]% to [N]% in unmoderated tests with [N] participants.
· Restructured settings navigation around user tasks instead of internal team boundaries, cutting settings-related support contacts by [N]% within one quarter.
· Mapped every error state in the payment flow and designed recovery paths, so a failed card now retries in place instead of restarting checkout.
設計系統與無障礙
· Rebuilt form patterns in the component library with engineering, replacing [N] one-off input variants and cutting design-to-build time for new pages to [N] days.
· Documented usage rules and code-linked examples for [N] core components, letting [N] product teams ship consistent UI without a design review per screen.
· Audited [N] key screens against WCAG AA, fixed contrast and focus-order failures, and added an accessibility pass to the handoff checklist.
成效驗證
· Defined success metrics with the PM before design started (activation rate and task time) and instrumented the flow so the redesign could be judged on data.
· Retired a personas deck nobody opened and replaced it with [N] task-based profiles tied to analytics segments the team could query.
· Re-tested the onboarding redesign [N] weeks after launch, confirming the [N]% completion lift held once the novelty effect passed.
跨職能說服
· Argued against a requested customization feature with recordings showing [N]% of testers never found the existing options; the release shipped [N] weeks earlier.
· Lost the navigation-placement debate, then designed the instrumented fallback that let the team reverse the decision on data one release later.
· Wrote a one-page design rationale for the pricing-page rebuild, so build-time questions went to the document instead of interrupting sprints.
改寫前後對照
同一段經歷的弱寫法與強寫法。why 指出的缺陷，比改寫本身更值得記住。
Responsible for the UI/UX design of the mobile app.
Owned end-to-end design for the mobile trading app’s onboarding and portfolio views, from research through shipped UI across [N] releases.
差在哪 · 「Responsible for」只說了座位在哪。改寫指名你擁有的流程（onboarding、portfolio views）、涵蓋的範圍（研究到上線）、與可追問的事實（[N] 個 release）。
Created personas, journey maps, and wireframes for the redesign project.
Mapped the renewal journey to locate a [N]% drop-off step, then redesigned the two screens around it, raising task completion from [N]% to [N]%.
差在哪 · 產出物清單只是活動紀錄。改寫讓 journey map 有了下文：定位到哪一步、改了什麼、指標動了多少。
Designed a modern and intuitive interface for the analytics dashboard.
Redesigned the analytics dashboard around the [N] most-run reports, cutting time to first insight from [N] minutes to [N] seconds in usability testing.
差在哪 · 「Modern」「intuitive」是自我評價，無法查證。改寫給出設計依據（最常跑的報表）與可量測的結果（time to first insight）。
Conducted user research to understand user needs.
Interviewed [N] churned subscribers, traced cancellations to a billing-surprise moment, and redesigned the upgrade flow; voluntary churn fell [N]% the following quarter.
差在哪 · 研究沒有改變任何決策，就還不算完成。改寫是完整的因果鏈：方法、發現、設計行動、指標變化。
Worked closely with developers to implement the designs.
Ran weekly build reviews with engineers, resolving spec gaps before QA and keeping [N] of [N] shipped screens within the documented design.
差在哪 · 「Worked closely」人人能寫，沒有資訊量。改寫給出機制（每週 build review）與可檢驗的結果（多少畫面照規格出貨）。
技能區怎麼取捨
原則一樣是可辯護，外加一條設計專屬：美感類的自評一律刪除，那是作品集的工作。
值得佔版面的
Figma · interactive prototyping · design tokens · basic HTML/CSS
moderated usability testing · user interviews · survey design · A/B test literacy
design systems · WCAG accessibility · developer handoff · design QA
funnel analysis · event tracking basics · experiment readouts
可以刪掉的
- 整套 Adobe 清單（Photoshop、Illustrator⋯） · 產品設計職缺比對的是 Figma 與設計系統經驗。列整套 Adobe 不加分，只讓人猜你上一次做產品介面是什麼時候。
- Creative、aesthetic sense 之類的自評 · 美感的證據在作品集，不在技能區。寫在紙上是雜訊，還占掉關鍵字的位置。
- Design thinking · 每份設計履歷都有這個詞，不產生區別度。流程能力用一個改變範圍的研究發現證明，比名詞有力。
- React、Vue 等前端框架 · 寫了就會被當半個工程師考。留 basic HTML/CSS 到能和工程討論實作成本的程度即可，除非你真的出貨過程式碼。
ATS 關鍵字
ATS 先比對關鍵字，人才看內容。以下是這個職位常被比對的詞，按類別分組。
只放你的經歷撐得起的詞。被追問答不出來，比沒寫更傷。堆關鍵字對解析器沒有用，在人眼裡只是雜訊。
不在履歷上的證據：作品集、案例，與不能公開的作品
設計是少數幾種「審履歷的人會離開履歷、去看第二份文件」的職業，而那份文件通常決定結果。履歷分給它的空間只有一行。這一節講那一行怎麼寫，以及對方點進去之後真正在讀什麼。
- 他們打開的順序，和你經營的順序相反
聯絡列的 URL、作品集首頁、案例標題，這三步加起來不到十秒。點進案例之後，多數人先滑到最後看結果，再回頭決定要不要讀過程。所以首頁如果不能讓人立刻知道該點哪三個，那是資訊架構的問題，而看的人正在拿這件事評估你；案例把「上線了什麼、指標動了什麼」放在第七段，等於沒寫。
- 履歷上指向作品集的那一行，逐字是這樣
聯絡列一行：Portfolio: yourname.design · password: hiring。密碼明碼寫在旁邊，投遞期間不要換。另外可以在對應的那段經歷底下再放一行，指名單一案例而不是首頁：Case study: checkout redesign, brief to shipped screens — yourname.design/checkout。指到案例比指到首頁少一次判斷，而每一次判斷都是對方可能停下來的地方。
- Dribbble 或 Behance 的九宮格答不出四個問題
一張圖回答「你能不能做出這種畫面」，然後就結束了。它答不出：這個案子的限制是什麼、哪幾個畫面是你的、上線了沒、上線之後發生什麼。這四題正好就是第一輪面試。圖庫要留可以留，但履歷指過去的地方必須是案例頁，因為只有案例回答得了這四題。
- 案例裡要自己指名哪幾個畫面是你的
產品設計幾乎沒有一個人做完的案子。案例只寫「我重新設計了結帳」，這句話會在面試裡被拆開問：研究誰跑的、視覺誰做的、範圍誰決定的。先把分工寫進案例——流程與互動我負責、視覺由團隊另一位設計師完成、研究和 PM 一起做。誠實標出範圍不扣分；被拆穿會讓頁面上其他每一句都重新估價。
- 上線的產品可以被查，你的數字不行
你說你做了某個 App 的開戶流程，對方可以直接下載那個 App 打開來看——這是設計師少數能被當場驗證的主張，也正是它值得寫的原因。麻煩在漂移：你交付的畫面可能已經被改過兩輪。案例標上時間與狀態（shipped 2024, redesigned since），現況和你的說法對不上時，是你先講的。證照同理：Nielsen Norman Group 的 UX Certification、IAAP 的 CPACC 要寫發證單位全名與年份，對方有給編號就附編號，還在考的寫 in progress，不要寫成已取得。
- 不能公開的作品：NDA、內部工具、還沒上線的東西
這類作品占資深設計師的大半。可行的做法是：客戶名換成類型（一家中型物流平台）、畫面裡的真實資料全部替換、案例設密碼並在跑完流程後停用，而且真的去問前雇主界線在哪。完全不能寫成案例的，履歷上就一行：details under NDA, walkthrough available in the interview，面試時用自己的螢幕帶對方看。把客戶的真實資料放上網，比作品集空著嚴重得多。
- 作品集還不能見人的時候，連結就不要放
三張未上線的視覺稿加一頁 Coming soon，比沒有連結傷得多，因為那是你自己挑出來代表「夠好」的樣本。這種時候改成把 Projects 區寫滿：一個概念研究，標明 concept，照工作專案的寫法寫研究發現、設計決策、測試結果。履歷先送，等一個完整案例做完再補上網址；作品集頁面晚幾天，不是壓著不投的理由。
設計師履歷的常見錯誤
- 1把履歷排成作品集
雙欄、自訂字型、大面積視覺，解析器都讀不出來，內容再好也進不了系統。手藝放作品集證明。履歷的形式就是保守，而選擇保守本身就是一個設計判斷。
- 2產出物清單當成成果
Personas、journey map、wireframe 是過程紀錄。看的人要的是這些產出改變了什麼：範圍砍了哪塊、指標動了多少。一條沒有下文的 deliverable，等於承認研究沒被用上。
- 3作品集連結不乾淨
一條可點的短網址就好：不放 QR code、不放縮網址、不放三個平台的連結；要密碼就把密碼寫在旁邊。每多一個步驟就多一次流失，而流失的那個人不會告訴你。
- 4每個專案都號稱 end-to-end
全部 end-to-end，等於沒有一段看得出你最強在哪。面試官會挑一個專案問到底；誠實標出你負責的段落，把 end-to-end 留給真的從頭做到尾的那一個。
- 5概念練習混進工作經歷
Redesign 練習可以放，但要進 Projects 區並標明 concept。未上線作品冒充上線被發現，代價是整份履歷重新估價。
- 6用形容詞替視覺品質背書
Clean、modern、pixel-perfect 是自評。視覺品質唯一的證據在作品集裡；履歷上的字句留給範圍、決策與 [N]。
每句主張會招來的追問
設計主張特別容易被追問方法與歸因。寫上去之前先想：這句話被問三層，你守得住嗎。
Raised task completion from [N]% to [N]% with the checkout redesign.
任務怎麼定義？受測幾人、怎麼招募？同一段期間工程端還上了哪些變更？
準備任務腳本、樣本數與招募來源。若同期還有其他改動，要能說明為什麼把變化歸因給設計。說不出歸因，數字會被當成裝飾。
Usability findings I presented cut two features from the release.
哪個發現？PM 原本的立場是什麼，你用什麼形式的證據讓決定轉向？
這題測的是影響力。準備完整敘事：發現、證據形式（錄影或數據）、誰反對、最後砍了什麼。沒有反對者的版本，聽起來像沒有發生過。
Built the design system components used by [N] product teams.
誰有權新增變體？講一個你拒絕收進系統的元件，和一個你讓步的。
設計系統的難題在治理，不在畫元件。要能講採用率怎麼量、阻力從哪來、規則在哪個案例上彎過。只有規則沒有例外的系統，多半沒人在用。
Cut onboarding drop-off by [N]% after the redesign.
Drop-off 定義在漏斗的哪一步？上線多久後量的？novelty effect 排除了嗎？
帶著漏斗定義與量測窗口。只量了上線後兩週就自己先講，並說明之後有沒有回測。自己先講的限制是嚴謹，被挖出來的限制是漏洞。
Shipped the redesign with engineering in a single release.
過程中你讓掉了哪個設計細節？怎麼決定哪些可以讓、哪些不能讓？
「什麼都沒讓」不可信。準備一個讓步和一個守住的例子，各附理由。這題測的是你能不能在真實限制裡做設計，而不只是在 Figma 裡。
常見問題
審履歷的人會先看履歷還是作品集？
先看履歷。履歷先過解析與關鍵字比對，再由人快速掃過。作品集是履歷贏來的第二關。兩份文件分工明確：履歷用證據換到點擊，作品集用手藝守住深看。
也因此作品集連結要零阻力：一條乾淨的 URL 放在聯絡列，需要密碼就附上密碼。
我是設計師，履歷用保守版型會不會顯得沒有 craft？
不會。看得懂媒介的設計師，知道履歷的形式就是單欄與標準標題。這是解析器決定的，跟品味無關。把履歷排成海報，是拿可讀性換對方根本收不到的風格。
這裡的版型全部單欄、標準標題，解析相容是內建的，不用自己再驗一次。
專案沒有數據可以量化怎麼辦？
先找替代證據：易用性測試的完成數（[N] 位受測者中 [N] 位完成）、支援工單的變化、設計模式被幾個團隊採用。這些都是守得住的數字。
真的沒有數字，就寫被改變的決策：哪個範圍因為你的發現被砍掉。這裡的生成器遇到缺的數字會留 [N] 空格，不會替你編一個。
職缺名稱有 UI/UX、product designer、interaction designer，履歷要跟著改嗎？
職稱列可以對齊 JD 的用語，這是關鍵字比對的現實。但 bullet 不用改：範圍、決策、[N] 成果，在哪個職稱底下都是同一套證據。
自主發起的 redesign 練習可以放上履歷嗎？
可以，獨立放在 Projects 區並標明 concept，寫法與工作專案相同：研究發現、設計決策、測試結果。新鮮人靠這區證明流程能力；但冒充上線作品的風險，永遠不值得冒。
讓履歷替作品集贏得那一次點擊
用中文照實描述你做過的專案、測試與改版結果，AI 以 Tech 視角改寫成本頁等級的英文 bullet。四項分數由規則引擎計算，同一份稿重測數字不變。缺的數字一律留黃色 [N] 空格由你自己填：任務完成率到底是多少，只有你知道。
免費生成 2 次