You spent weeks on your portfolio. Case studies with real process, honest constraints, before-and-after flows. It is the best proof of your work that exists. So the resume feels like a bureaucratic afterthought, and a slightly insulting one: why compress visual work into a text document when the real evidence is one click away?
Here is the uncomfortable answer: because the software that screens your application never clicks. Your portfolio link is, to an applicant tracking system, just a string of characters. Understanding this changes what the resume is for, and once you see it, the document becomes much easier to write.
The ATS never opens your portfolio
When you apply through a careers page, your resume is parsed into text and fields: names, titles, dates, skills, keywords. That text is what gets matched against the posting and what recruiters search. The portfolio URL sits inert in that text. No parser follows it. No ranking algorithm scores your case studies. In the screening stage, your years of craft are represented entirely by whatever words survive extraction from your resume file.
This is why brilliant designers with stunning portfolios sometimes cannot get callbacks: the decision about whether a human ever sees the portfolio is made by a system that cannot see design at all. If you want the full mechanics, see what an ATS actually reads from your resume.
So the honest division of labor is:
- The resume gets you retrieved. It exists for machines and skimming recruiters. Its job is carrying searchable, parseable facts.
- The portfolio gets you hired. It exists for the hiring manager and the panel. Its job is proving depth, process, and judgment.
Writing the resume gets easier the moment you stop asking it to do the portfolio's job.
The cruel irony: designed resumes parse worst
Designers naturally treat the resume as a design artifact: two columns, a sidebar of skill bars, icons for tools, text integrated with graphic elements. Every one of those choices fights the parser.
Parsers linearize your file into a plain text stream. What breaks, specifically:
- Multi-column layouts get read in the wrong order, splicing your sidebar into the middle of job descriptions. The details are in do resume tables and columns break ATS.
- Text inside images or exported graphics often is not text at all to the parser. If your tool list is a designed graphic, it may extract as nothing.
- Icons instead of words are invisible. A Figma logo is not the string "Figma," and the string is what gets matched.
- Skill bars and rating dots carry no machine meaning, and the labels next to them sometimes detach from their context.
- Decorative fonts and unusual glyphs can garble extraction in older systems.
The result is the industry's quiet joke: the more beautiful the resume, the worse the machine reads it. Your craft is real. It is just aimed at the wrong audience in this one document.
What belongs in the machine-readable text
Here is what the resume must carry as plain, parseable words, because this is what recruiters search and filters match:
Methods, by name
Write the actual craft vocabulary: user research, usability testing, user interviews, journey mapping, information architecture, wireframing, prototyping, interaction design, design systems, accessibility (WCAG). If you did it, name it. "I improve experiences" matches nothing; "moderated usability testing" matches searches.
Tools, as text
Figma, Sketch, Adobe XD, Maze, UserTesting, Dovetail, Miro, Zeplin, plus front-end familiarity if real (HTML/CSS, some designers honestly note "reads React, does not write it"). Spelled out in a plain skills section, not iconized.
Research and scope facts
- Planned and moderated 20+ usability sessions across 3 product areas over one year.
- Ran discovery interviews with 15 enterprise admin users; findings redirected the Q3 roadmap.
Numbers here are usually knowable and honest: sessions run, participants interviewed, flows redesigned, screens shipped.
Shipped work with outcomes, as sentences
The case study lives in the portfolio; its headline lives on the resume:
- Redesigned onboarding for a B2B analytics product (team of 1 designer, 4 engineers); completion of first-project setup rose from about 40% to about 60% after launch.
- Built and documented the component library in Figma now used by 3 product teams.
Honest hedges ("about," "after launch" rather than "because of me alone") keep every line defensible in the interview, where designers get probed on impact claims just like PMs do.
The portfolio link, prominent and plain
Top of the resume, as a readable URL. Machines ignore it; the human it is for should find it in one second.
Keep the applied resume clean, and treat that as a brief
The working answer used by many designers is two documents:
- The applied version: single column, standard headings, real text throughout, PDF exported from a text-based tool (not an image export). This is the one that goes through application portals.
- The expressive version: designed however you like, for humans you meet directly, conferences, referrals, or as a leave-behind.
If maintaining two feels wrong, keep only the clean one, and treat "single column, parseable, beautiful anyway" as a design brief. Type choice, spacing, hierarchy, and restraint still show craft. Any hiring manager who would reject a designer for submitting a parseable resume is telling you something useful about the job. The same two-document logic applies even more strongly to visual designers; see the companion guide on graphic designer resumes that ATS can read.
Tailoring: match the posting's design vocabulary honestly
Design job titles are chaos: UX designer, product designer, UX researcher, interaction designer often overlap. Postings differ in which words they use for the same work. So for each application:
- Mirror the posting's true terms. If they say "end-to-end product design" and that describes your work, use that phrase alongside your own.
- Lead with the overlapping methods. A research-heavy posting should meet your research bullets first.
- Never add a method you have not practiced. "Quantitative research" on your resume is an interview question about statistics you will have to answer.
The general method is in how to tailor your resume to a job description; for designers, the tailoring is mostly reordering and vocabulary matching, not rewriting.
Run your designed resume through the scan, then decide
There is a fast way to end the debate with yourself about whether your current resume is fine: look at what the machine actually extracts from it.
The free Beat the Bots scan at careerbounce.io shows you the raw text a parser pulls from your file, on your device, nothing uploaded. Designers are routinely shocked by the output: columns spliced into nonsense, the tools section gone because it was icons, a case-study headline missing because it was set inside a graphic. Whatever survives is your actual application, because that text is all the screening system ever sees.
Fix what the machine loses, keep the craft where humans will see it, and let each document do its real job. No resume and no scan can promise you interviews. But a designer whose words parse cleanly and whose portfolio delivers the proof is finally competing on the thing that matters: the work.