How to write a UI/UX designer resume
Updated 2026-09-02
A designer’s job search splits across two documents: the portfolio proves the craft, the resume supplies the evidence. Each resume line answers three questions. Did it ship? Did a metric move? Did scope change because of what you found? A resume written as a table of contents for the portfolio fails at both jobs.
That division shapes the writing. Personas, journey maps, and wireframes are records of activity. A working design bullet is verb-first, names the flow you owned, and ends in [N]: task completion from [N]% to [N]%. Every example on this page is English, because that is the output language of an international resume. Every number stays [N], because you are the one who defends it in the interview.
Below: why a designer’s resume should be the most conservatively formatted document you own, summaries by level, bullets grouped by competency, before-and-after rewrites, skills to keep and cut, ATS keywords, common mistakes, and the follow-up each claim invites.
What a finished one looks like
Below is a complete sample for a fictional person, rendered as a real page by the product's own sheet and scored by the same rules engine the editor uses — the number is computed, not typed in. Every figure a bullet owes is left as [N], which is why the score stops under the cap. That is not a flaw in the example; it is the product's rule, demonstrated.
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
Structure and section order
One column, standard headings, system fonts. For designers this rule feels backwards, which is exactly why it matters. Parsers cannot read two-column custom layouts. The reader also assumes you can match form to medium, and the resume medium is conservative. Styling it like a poster trades readability for flair the reader never receives.
The portfolio link lives in the contact line at the top: one clean, clickable URL. No QR codes, no link shorteners, no trio of platform links; if the portfolio needs a password, print the password next to it. Every extra step loses readers, and the lost ones never tell you.
- 1Summary
Three sentences: level, product domain, one defensible quantified outcome. This is where the reader decides whether to click the portfolio.
- 2Experience
Reverse chronological. Three to five bullets per role, naming the flows you owned, marking what shipped, ending in an [N] outcome.
- 3Selected Projects (optional)
Concept exercises and side projects go here, marked as concept. Entry-level candidates can move it up; written exactly like work.
- 4Skills
Three groups: tools, research methods, delivery practice. This is the keyword table, so list only what survives a follow-up question.
- 5Education
One or two lines for the design degree or career-change program. Bottom of the page after three years of work.
Summary examples by level
The summary has one job: earning the portfolio click. One example per level, numbers left as [N] for you to fill.
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.
Entry-level evidence is one real thing that shipped and got used, plus one real test. The last sentence previews the portfolio structure, which beats a software list.
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.
Mid-career means showing the full span of ownership, research through launch. The third sentence states a way of working: trading details inside engineering constraints. That is exactly what interviews verify.
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.
Senior evidence is direction changed: a roadmap turned by research, a system adopted by many teams. The last sentence also sets a standard: every case study ends on an outcome.
Bullets grouped by competency
Design bullets read best grouped by competency. The skeleton holds: verb, the flow you owned, method, an [N] outcome, or a decision that changed.
Research that changes decisions
· 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.
Flows and information architecture
· 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.
Design systems and accessibility
· 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.
Validation and measurement
· 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.
Cross-functional persuasion
· 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.
Before and after
The same experience written weakly, then well. The defect named in each why matters more than the rewrite itself.
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.
Why it works · “Responsible for” names a seat. The rewrite names owned flows (onboarding, portfolio views), a span (research through shipped UI), and a fact an interviewer can probe ([N] releases).
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]%.
Why it works · A deliverables list only records activity. The rewrite gives the journey map a consequence: which step it located, what changed, what the metric did.
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.
Why it works · “Modern” and “intuitive” are self-appraisal and cannot be verified. The rewrite supplies the design basis (the most-run reports) and a measurable result (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.
Why it works · Research that changed no decision is unfinished work. The rewrite is a complete causal chain: method, finding, design action, metric change.
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.
Why it works · “Worked closely” carries no information, because anyone can write it. The rewrite gives the mechanism (weekly build reviews) and a result you can check (how many screens shipped to spec).
What belongs in the skills section
The rule is still defensible, plus one designer-specific clause: delete every aesthetic self-appraisal. That is the portfolio’s job.
Worth the space
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
Cut these
- The full Adobe roster (Photoshop, Illustrator…) · Product design roles match on Figma and design-system experience. A full Adobe list adds nothing and invites guessing about when you last worked on product UI.
- Self-appraisals like “creative” or “aesthetic sense” · The evidence for taste lives in the portfolio, not the skills section. On paper it is noise, and it occupies a keyword slot.
- Design thinking · It appears on every design resume, so it sets you apart from nobody. Prove process with one research finding that changed scope. That beats any noun.
- Front-end frameworks (React, Vue…) · List them and you will be interviewed as half an engineer. Keep basic HTML/CSS at the level of discussing implementation cost, unless you have really shipped code.
ATS keywords
The tracking system matches keywords before a human reads content. These are the terms commonly matched for this role, by category.
Only claim terms your experience can defend. One you cannot discuss hurts more than leaving it out. Keyword stuffing does not move parsers, and a human reads it as noise.
The proof that is not on the resume: portfolio, case study, and work you cannot show
Design is one of the few fields where the reviewer leaves the resume to open a second document, and that document usually decides the outcome. The resume gets one line to point at it. Here is what the line says, and what the reader is actually doing after the click.
- They open things in the reverse of the order you built them
The URL in your contact line, the portfolio home page, the case-study titles: those three steps take under ten seconds. Inside a case study most readers scroll to the end first, look at the outcome, and only then decide whether the process is worth reading. So a home page that fails to make the three worth opening obvious is an information-architecture problem the reader is grading you on, and an outcome buried in the seventh section has not been written.
- The line on the resume that points at it, word for word
In the contact line: Portfolio: yourname.design · password: hiring. Print the password in plain text and do not rotate it while you are applying. You can add one more line under the role it belongs to, pointing at a single case study instead of the home page: Case study: checkout redesign, brief to shipped screens — yourname.design/checkout. A link straight to the case study removes one decision, and every decision is a place the reader can stop.
- Four questions a grid of shots does not answer
A Dribbble or Behance tile answers one thing, whether you can make a screen look like that, and then it is finished. It cannot say what the constraint was, which screens were yours, whether it shipped, or what happened after it shipped. Those four are the first interview round. Keep the grid if you want it, but the resume has to point at a case study, because the case study is the only artifact that answers them.
- Name which screens were yours, in the case study itself
Almost no product design work has a single author. A case study that says "I redesigned checkout" gets taken apart in the interview: who ran the research, who did the visual work, who set the scope. Write the split into the page — flows and interaction mine, visual design by another designer on the team, research run with the PM. Naming your part costs you nothing. Being caught inflating it reprices every other sentence on the page.
- The shipped product is checkable. Your numbers are not.
Say you designed an app’s account opening and the reader can install that app and open it — one of the few claims a designer gets verified on the spot, which is exactly why it earns the space. The catch is drift: what you shipped may have been redesigned twice since. Date the case study and mark its state (shipped 2024, redesigned since), so when the live product and your write-up disagree, you were the one who said it. Certifications follow the same rule: write the issuing body in full with the year — Nielsen Norman Group UX Certification, IAAP CPACC — add the credential ID if one is issued, and write an unfinished one as in progress rather than earned.
- Work you cannot show: NDA, internal tools, unreleased screens
This is most of a senior portfolio. What works: replace the client name with a type (a mid-size logistics platform), swap every piece of real data out of the screens, password the case study and retire the password after the loop, and actually ask your former employer where the line sits. Anything that cannot be written up at all gets one resume line — details under NDA, walkthrough available in the interview — and you walk the panel through it on your own screen. Publishing a client’s real data is a far worse problem than an empty portfolio.
- When the portfolio is not ready, leave the link off
Three unshipped visual comps behind a Coming soon page does more damage than no link at all, because the reader reads it as your own pick of your best work. Fill the Projects section instead: one concept study, labeled concept, written like work — finding, decision, test result. Send the resume now and add the URL once one complete case study exists. A page you are still building is not a reason to hold the application.
Common mistakes on designer resumes
- 1Designing the resume like a portfolio piece
Parsers read none of it: two columns, custom type, big visual moments. Content that never gets parsed never enters the system. Craft belongs in the portfolio. Choosing a conservative resume is itself a judgment about matching form to medium.
- 2Deliverables listed as achievements
Personas, journey maps, and wireframes are process records. The reader wants what they changed: which scope got cut, which metric moved. A deliverable with no consequence admits the research went unused.
- 3A messy portfolio link
One short clickable URL. No QR codes, no link shorteners, no three platform links; if a password is needed, print it beside the link. Every extra step loses readers, and the lost ones never tell you.
- 4Every project labeled end-to-end
If everything is end-to-end, nothing shows where you are strongest. Interviewers pick one project and drill; mark the parts that were actually yours, and save end-to-end for the one that truly was.
- 5Concept exercises mixed into work experience
Redesign exercises are welcome in the Projects section, marked as concept. An unshipped piece caught posing as shipped reprices the entire resume.
- 6Adjectives vouching for visual quality
Clean, modern, and pixel-perfect are self-appraisal. The only evidence of visual quality is the portfolio; resume lines belong to scope, decisions, and [N].
The follow-up each claim invites
Design claims get probed on method and attribution more than most. Before keeping a line, ask: does it survive three levels of questioning?
Raised task completion from [N]% to [N]% with the checkout redesign.
How was the task defined? How many participants, recruited how? What else shipped in the same window?
Bring the task script, the sample size, and the recruiting source. If other changes shipped alongside, explain the attribution. Without it, the number reads as decoration.
Usability findings I presented cut two features from the release.
Which finding? What was the PM’s original position, and what form of evidence turned the decision?
This question probes influence. Have the full story: the finding, the evidence format (recordings or data), who pushed back, what got cut. A version where nobody pushed back sounds like it never happened.
Built the design system components used by [N] product teams.
Who gets to add a variant? Name one component you refused to absorb, and one where you gave in.
The hard part of a design system is governance, not drawing components. Know how adoption was measured, where resistance came from, and where the rules bent. A system with rules and no exceptions is usually a system nobody uses.
Cut onboarding drop-off by [N]% after the redesign.
Where in the funnel is drop-off defined? How long after launch did you measure? Did you rule out a novelty effect?
Bring the funnel definition and the measurement window. If you only measured the first two weeks, say so first, and say whether you re-tested. A limitation you raise yourself reads as rigor. One that gets dug out is a hole.
Shipped the redesign with engineering in a single release.
Which design detail did you give up along the way? How did you decide what was negotiable?
“We compromised nothing” is not believable. Bring one concession and one detail you held, each with its reason. The question tests whether you can design inside real constraints, not only in Figma.
FAQ
Do reviewers look at the resume or the portfolio first?
The resume. It passes parsing and keyword matching first, then a fast human scan. The portfolio is the second round the resume earns. The division of labor is strict: the resume trades evidence for a click, and the portfolio holds up under the long look.
Which is also why the link must be frictionless: one clean URL in the contact line, password printed beside it if one is needed.
Will a conservative template make me look like a designer without craft?
No. A designer who reads the medium knows this one is single column with standard headings. The parser decided that, and taste had no vote. Styling the resume like a poster trades readability for flair the reader never receives.
The layouts here are all single-column with standard headings; parser compatibility is built in, so you do not have to verify it yourself.
What if my projects have no metrics to cite?
Look for substitute evidence first: usability-test completion counts ([N] of [N] participants), support-ticket changes, how many teams adopted the pattern. Those are numbers you can defend.
When there truly is no number, write the decision that changed: which scope got cut because of what you found. The generator here leaves a [N] placeholder wherever a number is missing. It will not invent one for you.
Postings say UI/UX, product designer, or interaction designer. Should my resume change?
Mirror the posting’s language in your title line; that is the reality of keyword matching. The bullets do not change: scope, decision, [N] outcome is the same evidence under any title.
Can self-initiated redesign exercises go on the resume?
Yes, in a separate Projects section, marked as concept, and written exactly like work: finding, decision, test result. For entry-level candidates this section carries the process evidence. Posing concept work as shipped is never worth the risk.
Make the resume earn the portfolio click
Describe your projects and test results in plain language. The Tech lens rewrites them into English bullets at the level on this page. The 0–100 score comes from a rules engine, so the same draft gets the same score every time. Missing numbers stay yellow [N] placeholders for you to fill: only you know what the completion rate really was.
Try 2 free drafts