There was a time when I thought that writing from the personal point of view made observations or advice weaker because they didn’t quote a ton of industry benchmarks or other authors. I generally don’t do that unless I’m debunking things like ATS fallacies or reported hiring benchmarks.

What I try to do is make my observations and advice actually usable. So when I tell you a password wall costs you the interview, I’m telling you what happens on any given night, after the kids are in bed, on the seventh resume-portfolio combo of the night.

What motivates me is simpler than some baby-food-bland mission statement. I am telling you the hiring manager’s side of the story. Candidates get advice from coaches, recruiters, influencers, and other candidates, and very little of it comes from the people making the calls. I make those calls on the daily and writing about it feels like a natural progression in my career. I am spilling tea.

None of this is gospel. Hold all of my musings up against your own experiences. Grab what speaks to you, and if you’re so inclined, argue with the rest. Some of you do, and your thoughts and arguments make every piece I write after it all the better.

Friday, I reviewed resume number 1,700

And boy is my brain ever tired.

When I am going through the process of reviewing interview materials, it is a series of judgment calls and those calls are a function of how close I am paying attention. As I hovered close to that 1,700 resume number, I could feel my mind, attention to detail, and energy start to wane. I was moving faster through each application and I was becoming less curious. That’s a big honkin’ red flag because candidates who deserve my full attention just aren’t getting it.

Now, a good percentage of those 1,700 applications were skimmed. I won’t apologize for that. However, when I am at my best, I work a little slower and I give materials the time, attention, and interest they deserve. It’s how I caught a fabricated resume and a truly excellent one in the same sitting.

My number of resumes threshold isn’t fixed and I don’t pretend to know where it actually sits. It moves depending on how much of the year is already behind me and how many hires still need to be made. Seven in a night? That’s a good working session. Seven in a night, just about every night over the course of nine months? That’s what’s turning my brain to mush and pushing me to take a break.

So I’m going fishing with the recruiter I run these loops with. After two decades of doing this, one of the things I value most is a partner whose read I trust and who tells me when mine is off. She has talked me out of a yes, and out of a no. I have done the same for her. Neither of us gets it right alone. We’re going to the river to fly fish and spend time together in blissful daytime silence and tall tales over cocktails and dinner.

There will be plenty of applications waiting for us. In the meantime, we’re doing a hard reboot and performing some much needed maintenance so we can come back with rested, curious minds.

When I get back, I will be publishing the longest thing I’ve written in a while on the topic of agentic tooling and my observations on how it is impacting the work of UX Design.

Underneath the trap is a darker assumption, and it’s the one I want to take apart: that the company (and the hiring process it runs) is built to keep you out. It isn’t. A company with an open role has a problem it needs solved, and every layer of the process is trying to find the person who solves it. Nobody builds a funnel to reject the right candidate. Believing they did is making you write worse resumes.

I’ll confess where the wrong frame comes from, because I reached for it myself. I fell down the RPG rabbit hole after 2020 (the games, then the LitRPG shelf including the Dungeon Crawler Carl series), and when I first sat down to write this, the structure came automatically: a boss gauntlet. Beat the ATS. Beat the recruiter. Beat me. Three enemies in a row, each one standing between you and the next.

It’s a great frame for a dungeon, but it is not for hiring. The three readers between you and an offer aren’t bosses, and they aren’t fighting you. Two of them are rooting for you. The third isn’t a person at all. The job hunt isn’t a gauntlet you survive. It’s a box with three locks, and one well-cut key opens all three.

The first lock: the ATS

Start with the layer everyone fears most, because it’s the one that isn’t even trying to stop you. The ATS is a machine, and people picture it as a bouncer, scoring their resumes and tossing everything under the line. That’s not what it is. There’s no universal score, and no employer ever sees the one those resume-checker tools invent for you. The machine reads your resume, pulls it into fields (name, contact, titles, dates, skills) and files it all in a database that a human can search later. Newer systems do a little more: rank candidates and flag how many of your bullets lead to an outcome. But the spine of the job is filing. The T stands for tracking.

Worth understanding the mechanism, because it tells you what matters. The system reads your resume once, on the way in, and breaks it into an index: your titles, skills, dates, and employers stored as searchable entries, the way a library catalogue files a book by author and subject. When a recruiter later searches “senior product designer, fintech, six years,” the system isn’t re-reading three hundred resumes; it’s looking up that index and handing back whoever’s filed under those terms. That’s why parsing matters so much: if your layout confused it on the way in, the index it built is wrong, and the search walks straight past you. You weren’t rejected. You were never retrieved. And the match score some systems paint on top of all this? It sorts the stack for a tired human; it doesn’t make the call. A person still reads down the list and decides.

It exists for reasons that have nothing to do with you. Post one role with an easy-apply button, and four hundred applications can land in a weekend. Nobody reads four hundred PDFs out of their inbox. The company needs them in one place, searchable, tagged by role, source, and stage, with a record of who applied and how they were handled, because at any serious scale that record is a legal requirement, not a nicety. An ATS is a filing cabinet built for volume and a paper trail built for compliance. Neither is a machine for rejecting you. If anything, it’s what keeps you from vanishing into the pile.

Take the famous number: “75% of resumes are auto-rejected by the ATS.” It traces to a single source, a 2012 sales pitch from Preptel, a résumé-services vendor that profited from your fear of the machines. From there, it spread, picked up by CIO and repeated by CNBC as a “study,” each retelling lending borrowed authority to a figure that never had one. HR consultant Christine Assaf traced the chain and went looking for the underlying research; there was none, and Preptel itself folded in 2013. Blunt machine auto-rejection, the kind the myth imagines, is rare: surveys put the share of employers who enable it at well under ten percent.

That doesn’t mean nobody gets filtered out. Plenty of qualified people do. Most employers admit that their own systems screen out viable candidates. But look at how it happens: a knockout question on work authorization, a keyword threshold someone configured, a recruiter who only reads the top of the stack. It’s authored by a human, not decided by a machine. A person almost always sees you; the only thing the software settles is whether they can find you when they look for you.

So tricking it is the wrong instinct. You don’t beat a filing system; you make its job easy, and it works for you. The white-text gambit, invisible keywords behind a white background, those tricks have been dead since around 2023 because the parsers flag it, and the moment a human selects all your text and the hidden word salad lights up, you haven’t beaten anything. You’ve shown them what you do when you think no one’s watching. Keyword stuffing fails more quietly: modern parsers match on meaning, not density, and unnatural repetition reads as noise.

Give the machine a clean structure it can parse, the titles and skills to be searched on, and outcomes it can index, and it files you correctly and hands you to the next reader intact. That’s the whole relationship. You don’t beat a filing system with adjectives. You make yourself easy to file and easy to find. That’s the first lock. It opens the moment you stop trying to pick it.

The second lock: the recruiter

Between the machine and me sits the reader almost nobody plans for: the recruiter. In my loop, she runs the first screen, and she’s the one whose hands are on the machine: she writes the search, sets the filters, decides who surfaces. Getting parsed cleanly matters because she is the one doing the looking.

But her screen is a different test than mine. I read your resume for the judgment behind the work. She reads it against a checklist I handed her: the must-haves, the level, the deal-breakers. She isn’t deciding whether you’re brilliant. She’s deciding two things: whether you clear the bar, and whether she can advance you to me without staking her credibility on a candidate she can’t explain. A thirty-minute screen has no room to untangle a mystery, so anything she can’t resolve, she has to treat as a risk.

That’s where good candidates lose a round they should win. A title that jumps two levels with no bridge. A pivot from enterprise to consumer, the resume never accounts for. None of these is disqualifying on its own. But left as an open question, each one forces her to either burn her time with you chasing it or pass you over for someone whose story she can present to me in one clean sentence. Make her job easy, and she becomes your advocate in a room you’re not in. Leave her holding questions she can’t answer, and she can’t do that with confidence.

This isn’t only my read from the hiring manager’s chair. Lindsey, the recruiter I work with, describes it as a writing problem:

Treat your resume as if you were writing anything else — the more specific a description or example, the better chance you have of making a connection with the reader. It’s storytelling about your own work and professional experience in a highlight-reel format of a resume. You need to inform that story with the most relevant, applicable, or transferable experience.

So write for the handoff. State your level plainly. Account for the anomalies before she has to ask. Hand her the one-line version of why you fit, because that's the line she's going to repeat to me. That's the second lock.

The last lock: the hiring manager

By the time you reach me, your resume has one job: give me something to ask you about when we talk for the first time. I’m not reading your resume for elegance. I’m reading it for the falsifiable claim: the line specific enough that your answer during the screen will either hold up or fall apart in real time.

“Led design for the checkout redesign” isn’t that. I can’t build a question on it. “Cut checkout abandonment from 31% to 19% by rebuilding the address step.” Now I have a screen. What was breaking? Why the address step and not the payment one? How did you separate your design from everything else shipping that quarter? A resume full of the first kind of line is one I can’t interview. A resume full of the second kind interviews itself.

Vague bullets read as risk to me, the same way a keyword wall reads as risk to the parser. If you can’t tell me what you did, I assume you don’t know, or didn’t do much. The machine files you. The recruiter vouches for you. I interrogate you. Give me something worth interrogating. I’m the last lock, and I only open for work that I can ask for specifics on.

One key for all three locks

Here’s what nobody selling keyword tricks wants you to know: the specific, quantified bullet isn’t a trick for any one reader. It works on all three at once. “Managed a team” tells none of us anything. “Managed a team of eight and cut delivery time 22%” gives the parser something to index, the recruiter a line to repeat, and me something to interrogate. One bullet, three readers. And the payoff is measurable: the largest field experiment on the question, nearly half a million jobseekers, found that better-written resumes got people hired 8% more often, not because the writing faked ability, but because it made the ability they already had easier for employers to see. That’s the whole game in one finding.

Semantic matching closes most of the remaining gap. The parser already knows “product design,” “UX design,” and “interaction design” are the same craft wearing different name tags. You don’t need to cram every label onto the page. You need the honest words for the work you did, which is what you’d write anyway if you were describing it straight.

There is exactly one place it pays to copy the posting, and it’s worth doing: the title. Jobscan’s data puts the exact job title from the listing as the single highest-impact line on a resume: by their count, more than tenfold on interview odds. Semantic matching forgives a synonym anywhere else on the page, but not in the title field, which carries the most weight and anchors the recruiter’s search. Here, “close enough” loses to the exact string. If the posting says “Senior Product Designer” and your title was “Product Designer III,” don’t lie and don’t bury it. Put the equivalent in plain sight: Product Designer III (Senior Product Designer level). The parser finds the match. I see an honest bridge instead of a gap I’d otherwise wonder about.

That’s the title. Don’t extend the logic to the rest of the page. Job-posting voice was the first thing I went after last time (the “passionate about end-to-end ownership in a fast-paced, data-driven environment” register job descriptions are written in), so let me be clear, I’m not telling you to write in it now. Copying the title matches one searchable label. Writing your experience in the posting’s voice is the same mistake as stuffing keywords: optimizing for a reader who doesn’t grade content, and handing the one who does, me, a page with no work on it. Mirror the title. Never the voice.

The three-lock box

Enough principle. Here’s what it looks like on the page.

This is a bullet written to beat the robot, packed with every keyword the posting might search for and nothing a human can use:

Utilized user-centered design, design thinking, wireframing, prototyping, agile, and cross-functional collaboration to drive data-driven, customer-obsessed solutions.

It loses on all three locks at once. The machine sees a keyword pile with no work around it, and modern parsers downrank exactly that: terms with nothing to match against. The recruiter can’t tell what you did or what level you did it at, so she has nothing to carry to me. And I have nothing to ask. It’s a competencies checklist, not a thing that happened.

Same candidate, same job, re-cut to open all three:

Owned the onboarding redesign: wireframed and prototyped three approaches, A/B tested them, and shipped the one that cut first-week drop-off from 48% to 31%, about 12,000 new users a month.

Watch what each lock does with that. The machine still gets its keywords (wireframed, prototyped, A/B test), but now they’re attached to work it can index. The recruiter gets a line she can repeat to me in one breath: owned an onboarding redesign, moved drop-off thirteen points. And I get three threads to pull in the screen: why those three approaches, what the losing ones taught you, how you separated your design from everything else shipping that quarter. Same skills, same person. One version is noise. The other is a key.

Two more, quicker.

Leadership, inflated for the recruiter’s eye:

Led cross-functional teams to deliver impactful product experiences end-to-end.

becomes

Led the design for the billing redesign across a PM, three engineers, and a researcher. No direct reports. I set the direction in a kickoff doc the team aligned on, then designed and shipped it over two quarters.

Same verb. What changed is the specificity, and the honest clause, no direct reports, kills the question the recruiter would otherwise have to chase (is this person claiming they managed people?) while handing me the kickoff doc to ask about.

The number with nothing behind it:

Increased engagement 200% and drove revenue through innovative design.

becomes

Redesigned the dashboard’s empty state; weekly active use of the feature went from 12% to 27% the quarter it shipped.

The first reads as retrofitted and turns into a credibility probe. The second hands me the attribution caveat before I can ask for it, which is the fastest way to make me trust the number.

What to do

• Match the title. The exact job title from the posting is the single highest-impact string on your resume. Recruiters search on it, and the parser weights it. Put it where it gets found: a headline under your name, or your summary line. What you don’t do is relabel your past roles to match it. That’s a lie that unravels in the first thirty seconds of a screen. If your most recent title was Product Designer III, don’t fake it and don’t leave the mismatch sitting there unexplained; bridge it once, in plain text: Product Designer III (Senior Product Designer level). The title is the only place where copying the posting helps you.

• Avoid writing in the posting’s voice. The title is a label you match; the voice is the register the posting is written in (the “passionate, data-driven, customer-obsessed, end-to-end” fog), and you never describe your own work in it. It reads as empty to me and as noise to the parser. “Drove data-driven, customer-obsessed outcomes” is the posting talking. “Rebuilt the search filters and cut zero-result queries by a third” is you.

• Use the vocabulary of the work. The keywords are already inside an honest description. You don’t bolt them on; you write the sentence that contains them.

• Quantify. A number feeds the parser’s achievement score, gives the recruiter a line to vouch for, and hands me a thread to pull. Same bullet, all three readers, no tradeoff.

• Resolve the anomalies yourself. A title jump, a gap, a domain pivot: if it’s on the resume, account for it on the resume. The recruiter can’t advance a question she can’t answer, and a thirty-minute screen won’t fix what a single line could have.

• Keep the structure clean. One column, standard section headers, no text boxes or graphics the parser will choke on. It’s the clean, simple format career offices recommend, and the one parsers read most reliably. The fancy two-column export from your design tool is what scrambles the read; the PDF format itself is fine, since every major system reads it now.

• Put keyword-completeness where it belongs. A skills line can carry the exact terms a recruiter searches without turning your experience into word salad. Vocabulary in the skills section, evidence in the bullets.

• Answer the knockout questions straight. Years, location, authorization: the few things that can filter you out automatically. Don’t lose on a technicality you could have settled in one line.

• Retire the dead tricks. White text, invisible keyword walls, density padding. They don’t work, parsers flag them, and the instant a human selects all your text, you’ve shown them who you are.

Bottom line

The company was never out to get you. The people who told you this are mostly the ones selling you the tricks to beat it. There’s no robot stamping REJECT on qualified people for the wrong synonym, no recruiter hunting reasons to toss you, no hiring manager hoping you fail. A company with an open role is a company with a problem, and every layer of the process is someone trying to solve it by finding you. The whole apparatus is rooting for a yes.

All three are reading for the same thing underneath: evidence you did the work, in the plain words of someone who did it. That’s the key that opens all three locks.

So stop writing for a robot you were told to fear. Write the resume that survives the room at the end. Mine. Make that key, and the machine files you correctly, the recruiter walks in on your side, and the only fight left is the one you came to have: showing that you are the right person to do the job. That’s the fight. It’s the only one that was ever about you.

I don’t take it. Not because I’m cold, and not because I’m too busy — though I am. I don’t take it because the call you’re asking for is a worse version of a process that already exists, and saying yes to it would be unfair to every candidate who didn’t think to slide into my DMs.

Let me walk through why.

The call doesn’t do what you think it does

Some designers think a connect-and-chat gives them an edge — face time, a chance to make an impression, a way around the pile. It does not. It tells me you’re hoping for a side door because you’re not sure you can get through the front one.

Here’s what people want from that call, point by point, and where each one already lives:

• What the role actually involves (that’s in the job description — the real one, not the LinkedIn one-liner)

• Whether I think you’re qualified (that’s what your resume is for)

• Why you’d be good at it (that’s your cover letter, if you write one)

• A look at your work (that’s your portfolio)

Every question the call would answer is a question the application already answers — better, on the record, and reviewable by people who aren’t me. The call adds nothing except pressure on both of us to perform rapport neither of us asked for.

It isn’t a level playing field

This is the part that matters most.

If I take a call because you found my profile and wrote a good opener, I’m rewarding access, not ability. The candidate who applied through the posting at 11pm after their kid went to bed — no warm intro, no clever DM — gets evaluated on their work. The candidate who DMs would get evaluated on their work plus a head start I handed out for free.

I’m a hiring manager. My job is to run a fair process that finds the best person, not the most networked one. The minute I start taking these calls, I’ve made “knows how to reach Julie” a hidden evaluation item. It isn’t on the job description. It shouldn’t be on the rubric.

Networking is the recruiter’s job — and she’s already doing it

There’s a version of you that genuinely just wants information — is this role remote, what’s the level, is it still open. Fair questions. I know all of it; I set the level, the band, and the loop with HR and the recruiter jointly. But me answering you in a DM isn’t a process. It’s a favor, handed to whoever finds my profile.

The connecting is a job — and initially it’s the recruiter’s, not mine. When she accepts a request to connect ahead of a role, that’s passive sourcing. Scouting. A legitimate, intentional part of recruiting, run against everyone in the same way. When you route it to me instead, you’re asking the hiring manager to do the recruiter’s job off the books, for an audience of one. Apply, and the sourcing conversation you were trying to have happens where it’s supposed to — with the person whose job it is, on the record.

The one DM I don’t mind

There’s a version of the message that’s fine. You apply through the posting — first — and then you send a note. “Just applied for the Senior Product Designer role, really excited about it, looking forward to hearing from the team.” No ask. No call request. No side door.

I probably still won’t reply. But I won’t reach for the Ignore button either. You did it in the right order: process first, courtesy second. That sequence tells me you understand how this works, and I’ll remember the name instead of someone who tried to skip the line. It’s a small thing. It counts more than the people sending it realize.

What actually moves your candidacy

I read every application that comes through the posting. I do not read every DM. So:

• Apply through the posting. It puts you in the system the recruiter and I both work from. A DM puts you in a queue of one, behind everyone else’s DMs.

• Make the application do the talking. Tight resume, a portfolio I can get into without emailing you for a password, a cover letter that names why this role. That’s your call. That’s the conversation. You just get to script it in advance instead of improvising it on a call.

• If we’ve worked together, or you have a specific question only I can answer — that’s different. Connect. I’m a person, not a wall.

Bottom line

I’m not ignoring you. I’m holding the line that keeps the process fair to the people who didn’t get to skip it.

The application is the conversation. The portfolio is the impression. The front door is unlocked — use it.

Connect because you want to be in my network. Not because you think it gets you the job. It doesn’t.

The first ten seconds

I close most portfolios before reading a word of the work. Five things decide, roughly in the order I hit them: hero line, craft, homepage, password walls, papercuts.

Hero line. I see this first. One sentence. What kind of designer are you? Where do you sit? Four words will do it. Seven is plenty. “Design Alchemist & Experience Architect” is not that. “I craft thoughtful experiences at the intersection of strategy, technology, and humanity” is not that either. Everyone lives at that intersection. It’s crowded. There’s a Starbucks. Some designers think a creative tagline shows personality, range, or differentiation. It does not. It shows you’re performing seniority instead of describing it. The fix: replace the noun with a verb, the title with the work, the sensibility with a point of view. “Senior Product Designer on AI-enabled systems” beats “Design Alchemist.”

Lately, there’s a specific version of this I have to call out. Every third portfolio in the last six months shoves AI into the hero line. “AI-native product designer.” “Pioneering human-AI collaboration.” “Designing the agentic future.” Everyone knows AI is what hiring managers are listening for. Everyone’s claiming it. Most of it is bullshit, and I can tell in the interview. More on that below.

Poor design choices. Aggressive palettes. Weird fonts. Unnecessary design elements — animations that serve nothing, spinning cursors, parallax scroll for its own sake, a hover state on every element because why not. The portfolio is itself a design artifact. Weak craft, weak claim. If I’m distracted by the container, I’m already skeptical of the contents. And when I see wild design choices in the one artifact you fully control, the one meant to showcase your best work, I don’t think “creative.” I think risk. If this is the judgment you bring to your own portfolio, I can’t trust the judgment you’ll bring to my product.

Homepage shape. Projects visible in one scroll. The strong homepages lead with impact up front — Problem / Solution / Impact, or the metric itself: 1000+ scripts in month 1. $2M+ saved. 78% faster onboarding. Whatever format you choose, the outcome should be the first thing I see, not the last. The weak ones hide the work behind empty section headers — “Crafted to Impress, Built to Perform.” “Tailored Solutions, Impactful Result.” “Voices of Trust and Success.” Real headers from real portfolios that exist only to fill space. Skip them altogether. They bring nothing to the party.

Password walls. If the work is behind one, I’m not emailing you. Some designers think a password wall encourages engagement — creates intrigue, makes me reach out, starts a conversation. It does not. It tells me you don’t understand how hiring managers scan. I have 40 portfolios to get through tonight. The ones without friction win. One project behind a wall for confidentiality is fine. All of them means you don’t want the job.

Papercuts. Small details that telegraph carelessness. One is forgivable. But they stack, and a dozen of them stacked together is a bad club sandwich I have to eat before I can get to the work. A contact email like yourname456@gmail.com after a decade in the field, sitting next to a Bank of America case study. A custom domain costs $4 a month; the numbered Gmail tells me you never cared enough to fix it. “Website Rewamp” on a live portfolio (yes, really — I’ve seen it). A site that can’t decide if you have 6 or 8 years of experience. Random mid-word capitals in your own name. “Pixel-perfect” in the bio, typo on the featured project. These details are free. Not getting them right is a choice.

Clear the gate, and here’s what I look for if I make it past the first ten seconds without throwing my laptop out the window.

The six questions

Miss any, and I’m left guessing. You do not want me to guess.

1. Who are you?

Not your job title. Your point of view. “UX/Product designer blending strategy, empathy, and visual storytelling” is a template I could generate in my sleep. Tell me you spent six years on financial products. Tell me you’re the person teams call when the IA is a mess. Specificity filters. Right roles find you faster. Wrong ones bounce.

2. How do you think?

Where most portfolios collapse. For a senior role, how you think is the job.

The Boneyard. The ugly middle. Wireframes, dead-end flows, the three alternatives you weighed. Process beats polish every time. Polished screens are the gift wrap. The Boneyard is the gift. Some designers think polished final screens make the strongest case — that messy process work looks unfinished or unprofessional. It does not. It hides the thinking I’m actually hiring for. I don’t hire Figma files. I hire the judgment that produced them.

Three signals of senior thinking that almost nobody surfaces:

Systems thinking. Where does the feature sit? Which workflows does it depend on? Where did you trade off performance vs. flexibility, or simplicity vs. configuration? One flow on one screen is IC craft, not design leadership.

States and back doors. One hard interaction, full state space — happy, error, empty, loading, recovery. Show me the back door for the power user who knew your product better than you did. A senior designer who only shows the happy path doesn’t know the other paths exist.

The direction you didn’t ship. Most underused move in portfolio writing. One path you explored and rejected, and why. “We considered X, tested with [n] users, learned [Y], moved on” is a one-paragraph proof of seniority.

3. Show me your growth.

Three projects are not a trajectory. It’s a highlights reel.

Different contexts. Year five harder than year two. If every project looks the same, you haven’t grown — you’ve gotten fluent at one thing and stopped.

Tell me about a moment where critique or research changed your direction. Name the feedback, the source, and what you did. A designer who can’t point to a single mind change is either lying or not paying attention.

Ten years and three projects? Either most is under NDA (fine, say so), or you haven’t worked on enough different things. Address it.

4. Show me your impact.

If it isn’t measurable, it isn’t impact. It’s activity.

Give me the data that informed your design decisions, and then tell me how the work had impact. 1.2M customers engaged. 60% fewer support tickets. Day 3 drop-off cut from [baseline] to [X]. If the numbers are confidential, frame their direction and magnitude. “Improved engagement” means nothing.

Better: you and your PM defined success together. Activation, task success, time-to-value, quality. If metrics first appear in the part where you report them, you didn’t choose them.

“Defined the interaction architecture and clarified the MVP for engineering handoff” is a deliverable. What happened after you shipped?

5. What are you learning?

Nobody answers this. That’s why answering is an easy win.

One line. One current obsession. “Deepening my design systems practice.” “Weekly pottery practice changed how I think about iteration.” Anything that says you’re still hungry.

Usually: silence. A designer who stopped learning in 2019 is not the kind I’m hiring.

6. How do you work with others?

Design is a team sport. Every portfolio treats it like a solo exhibition.

Your role, stated. Who you partnered with. Decisions you owned vs. those you didn’t. Named handoffs, named workshops. If you fought for a position and lost, say so.

I listen to the verbs. “I decided. I pushed for. I pushed back.” That’s ownership. “We shipped. The team built. It was decided.” That’s someone who was in the room but didn’t drive.

Show me a moment of disagreement. A scope cut, a PM direction you pushed back on, a handoff that nearly went sideways. Conflict-free collaboration is a lie, and telling it makes you sound junior. Senior designers have scars. Show me.

Testimonials are other people’s words. I want yours.

On AI, specifically

Three patterns I see most often right now. There are probably others — people are creative — but these three come up again and again, and they’re genuinely different jobs.

1. Designing with AI — Claude, Cursor, v0, Figma AI as tools in your process.

2. Running research with AI — agentic tools for dataset synthesis, competitive scans, large-scale user data.

3. Designing for AI — products where AI is the core experience. Chatbots, copilots, agents, generative UIs.

Tell me which. Specifically.

With AI: which tools, for what, what changed. “I prototype in Cursor instead of static Figma mockups” is a sentence. “I leverage AI in my design process” is a reflex.

Research with AI: which agents, which datasets, what you found, how you verified. “I ran 40 interview transcripts through Claude for first-pass synthesis, then reviewed the underlying quotes to discard the patterns that didn’t hold” is a sentence. “I use AI for user research” is a wishlist. If you can’t tell me what the agent got wrong and how you validated what you kept — that’s not research. That’s delegation.

For AI: the specific UX problems. Trust. Control. Confidence signalling. Latency. Attribution. Error recovery when the model is wrong. The autonomy-vs-confirmation trade-off. These separate shippers from keynote-watchers. Claim “agentic design” and I’ll ask what your agent should do when it’s uncertain. “Ask the user” — with no follow-up on when, how, with what framing, and how often before it’s annoying — means you haven’t shipped.

Done none of this? Say so. “I haven’t shipped AI features yet, but I’ve been using [tools] to change how I work, and I’m interested in [area] because [reason]” beats a fabricated claim that falls apart in the interview. The worst move is the middle ground. Enough vocabulary to look current, not enough substance to survive the follow-up. Fluent to a recruiter. Fraudulent to a hiring manager.

Bottom line

Two jobs. Survive the ten seconds. Answer the six questions. Most portfolios fail the first. Most that clear question one will fail on question two — how you think. The gap between a portfolio that gets you the interview and one that doesn’t is smaller than designers think, and almost all of it is fixable in a weekend.

Look at your site honestly. If your hero line reads as AI-generated, it did. If your case studies are galleries, rebuild them. If you can’t answer one of the six, that’s where the work is.

The first ten seconds are the interview. Everything after that is the confirmation. Clear the portfolio, and you earn the presentation — a different job with its own failure modes. That’s the next piece.

Here’s the framework I run.

Three categories, not one

When a designer says “I work with AI,” they could mean three different jobs. Conflating them is the first mistake — for the candidate and for the hiring manager reading their materials.

1. Designing with AI — using AI tools in your design process

2. Running research with AI — using agentic tools to synthesize at scale

3. Designing for AI — shipping products where AI is the core experience

Each has its own substance check. Each has its own way to fail.

Designing with AI

Process change. Claude, Cursor, v0, Figma AI, Figma Make, Figma MCP, ChatGPT — pick your stack. The question isn’t whether you use these tools. It’s what changed in your work because you do.

Substance looks like: “I prototype in Cursor instead of static Figma mockups.” “AI-assisted prototyping with Figma Make compressed concept-to-test cycles from weeks to days.” Specific tool, specific use case, specific outcome. These are sentences.

Vocabulary-only fail: “I leverage AI in my design process.” “AI-assisted workflows.” “Modern AI-augmented tooling.” Reflex, not substance.

The probe is short: pick one tool. Walk me through what changed in your process. What do you measure to know it’s working?

If you can’t answer without retreating to the keywords on your resume, the resume was the work.

Running research with AI

Using agentic tools for dataset synthesis — interview transcripts, competitive scans, large-scale user data. Different muscle than designing with AI, even when the same tools show up.

Substance looks like: “I ran 40 interview transcripts through Claude for first-pass synthesis, then reviewed the underlying quotes to discard the patterns that didn’t hold.” The verification step is the tell. The candidate knows what the AI gets wrong, and they can describe what they did about it.

Vocabulary-only fail: “I use AI for user research.” “AI-powered insight synthesis.” Wishlist, not work.

The probe writes itself: walk me through one piece of research where you used AI for synthesis. What did the AI get wrong? How did you validate what you kept?

A designer who has done this work can describe a moment where the AI confidently summarized a pattern that wasn’t there — and what they did to catch it. A designer who hasn’t will hedge.

Designing for AI

The hardest category. You’re shipping products where the AI is the core experience — chatbots, copilots, agents, generative UIs, AI features inside an existing product.

The bar is highest because the design problems are hardest. Trust. Control. Confidence signaling. Latency. Attribution. Error recovery when the model is wrong. The autonomy-vs-confirmation tradeoff — what does the agent do when it’s uncertain?

Substance looks like: a specific position on what your agent does when it’s not sure. “Ask the user, with these framing rules, this often.” Concrete defaults, concrete tradeoffs, concrete language for confidence states.

Vocabulary-only fail: “Designed AI-assisted workflows and contextual guidance systems improving usability and trust in complex financial processes.” Textbook-bullet phrasing. Could be lifted from any AI-UX best-practices guide. Often was.

The probe: pick one AI feature you shipped. What does the AI do when it’s uncertain? What defaults did you set? What does the user approve before it happens, and what can they undo after?

Generic answers are visible the moment they leave a candidate’s mouth.

The middle ground is the worst place to be

Real talk: the riskiest position on a resume is fluent enough to clear a recruiter screen, thin enough to collapse in mine.

Detection signals:

• AI keywords stacked in a Skills section with no specific work behind them

• Resume bullets that read like best-practices summaries instead of work

• “Trust,” “transparency,” “human-in-the-loop” used decoratively, with no concrete example

• Coursera or Udemy AI-design certificates with no shipped AI work to anchor them

• Claims spanning all three categories with depth in none

The middle ground gets you to the screen. The screen ends the conversation.

“I haven’t shipped AI features yet”

Direct call-out: candidates who don’t have AI work to point to.

A clean answer beats a fabricated one. Every time.

“I haven’t shipped AI features yet, but I’ve been using [specific tool] to change how I work, and I’m interested in [specific area] because [specific reason]” — that candidate I keep talking to. They told me where they are. They told me where they’re trying to go. They didn’t pretend.

Stuffing AI keywords across a resume to hide the gap doesn’t hide it. It marks it.

What this is really about

The AI fluency check isn’t really about AI. It’s about whether a designer can describe their own work with specificity — what they did, what changed, what broke, what they fixed.

If the answer to “how do you use AI?” is a sentence I could lift from a vendor blog post, it tells me how the candidate describes everything else they’ve worked on, too.

The vocabulary is free. The work isn’t. I’m hiring the designer who can tell me, specifically, what they did.

I read seventeen of them this morning. The thing is, I read your resume in there, too — or what felt like your resume. The bullets — the actual sentences describing the work — were close enough to identical across all seventeen that I could have shuffled them, redistributed them across the seventeen names, and not changed the meaning of any of the candidacies.

‘Conducted user research, journey mapping, and usability testing to inform design decisions.’

This sentence is on four of the seventeen resumes in front of me right now, almost word-for-word. Four different candidates. Four different industries. One sentence.

‘Led end-to-end design from discovery through launch, collaborating with product managers and engineers.’

That one’s on seven.

‘Designed scalable, accessible, intuitive experiences across platforms.’

Five. I stopped counting.

This is the hiring problem most candidates don’t realize they have.

A vague bullet is annoying on its own. A vague bullet that’s a near-copy of four other people’s vague bullets is invisible. You’re not sending me a resume. You’re contributing one more entry to a recognizable template. I’m not deciding whether to like your bullets. I can’t see them anymore. They’ve stopped being information.

There are five ways resumes go generic. I’m going to walk through each one. Each has a specific mechanism, a specific cost when it hits my screen, and a specific fix. The fix is the same in spirit every time: write the bullet nobody else applying for this job could plausibly have written. The bullet that’s anchored to a decision you made, a constraint you faced, a number you measured — something that can’t be ported across to the resume of the next candidate in my stack.

Here’s the test for every bullet on your resume. If I took your name off the top and read this bullet to fifteen other designers at your level, would any of them recognize it as something they could have written too?

If yes — cut it. That’s what makes you the 17th.

1. The bullet that says nothing

Here’s a bullet from one of those seventeen resumes:

‘Partnered with product leadership to define feature priorities and translate user insights into scalable product solutions aligned with business goals.’

Read it twice. Now tell me what they did.

You can’t. Nobody can. The bullet has nine nouns and four verbs, and not one of them is the work.

The problem

This is job description voice — language lifted from the posting, not from the doing. ‘Partnered with’ means they were in meetings. ‘Define feature priorities’ is a meeting outcome. ‘Translate user insights’ — what insights, into what? ‘Scalable product solutions aligned with business goals’ — does any company anywhere ship products misaligned with its goals?

Three things are happening at once.

The JD is bleeding into the resume. When you’ve read a job posting fifty times before clicking apply, the language of the posting starts to feel like the language you’re supposed to write in. So you mirror it. ‘Cross-functional collaboration.’ ‘Strategic alignment.’ ‘End-to-end ownership.’ These are hiring-committee words — the vocabulary of the people writing the JD, not the people doing the work. When you mirror the JD’s voice, you’re filling out the opening rather than answering it.

Strategic-sounding nouns feel safer than concrete ones. ‘Scalable product solutions’ feels professional in a way that ‘redesigned the checkout flow’ does not. The first sounds like an executive summary. The second sounds like work. Designers — especially designers stepping up a level — reach for the executive register because they think it signals seniority. It does not. It signals that they don’t trust the work to speak.

The abstract bullet is emotional protection. A specific bullet is a claim that can be cross-examined. ‘Reduced checkout abandonment 18% over six weeks’ is a number a hiring manager can ask about in a screen — and a number a candidate could remember wrong, defend badly, or get cornered on. The vague version is safe. ‘Translated user insights into scalable product solutions’ can’t be cross-examined because there’s nothing in it to cross-examine. The candidate stays unbothered. The candidacy gets cut.

The pattern produces a specific archetype. JD-voice writers use some abstract bullets at the junior level and most abstract bullets at the senior level. The bullets get more abstract precisely as the underlying work gets more substantial. By year eight, the page is a wall of strategic-sounding nouns, and the actual decisions the candidate has owned are nowhere on it.

Why does this not resonate with hiring managers

I scan 200+ resumes for an open role. Each one gets about ten seconds before I decide whether to keep reading. In those ten seconds, I’m looking for something to ask about during a screen. A specific project. A constraint. A decision. A trade-off. A number with a baseline I can poke at.

A bullet like ‘partnered with product leadership to define feature priorities’ gives me nothing to ask. I can’t say “tell me more about that” because there is no that. It’s pattern-matching language. Every product designer ‘partners with leadership.’ Every product designer ‘translates insights.’ If I covered the company name at the top and showed you the bullet, you couldn’t tell me what kind of product this designer works on, what industry they’re in, or what made a single project interesting enough to remember.

When I see a wall of these, I assume one of three things:

• The candidate didn’t do enough specific work to fill bullets, so the bullets got filled with role description.

• The candidate doesn’t know what’s worth telling — which is a judgment problem.

• The bullets got copied and pasted from the JD because the application took five minutes, and that’s about what it deserved.

The judgment problem is the one that matters most. A senior designer’s job is to know what’s worth telling. It’s the same skill they’d use briefing engineers on what to build first, presenting work to stakeholders, and deciding what makes it into a portfolio case study. When the resume’s selection comes back as ‘partnered with leadership’ and ‘translated insights,’ it tells me the candidate either didn’t do the curation or didn’t know how. Either read ends the application before the screen.

The fix

Write the bullet only you could have written.

That’s the standard. Not “be more specific in general.” Specifically, if I removed your name from the top of the page and read the bullet to fifteen other designers at your level, none of them should recognize it as something they could plausibly have written about their own work. The bullet should point back to you and only you.

The mechanics:

• Lead with the artifact. Name the thing — the checkout flow, the spend-controls surface, the onboarding sequence, the IA restructure. Not the category (‘optimized conversion experiences’). The thing. The reader should be able to picture a specific screen or system in their head by the end of the noun phrase.

• Name the constraint that made it interesting. What was the trade-off? The technical limit? The alternative you rejected? A specific constraint is what makes a bullet unrepeatable. Anyone can claim they ‘designed a checkout.’ Only you can describe the architecture call you had to make on day three when the platform team told you about the rate limit on the third-party address-verification API.

• Anchor outcomes to a baseline. ‘40% mobile conversion lift’ isn’t enough on its own. ‘40% mobile conversion lift over the existing three-step flow, measured across 14,000 weekly sessions in a six-week A/B test’ is enough. The numbers don’t have to be huge — they have to be defensible.

This same resume already passes the test in one section. Further down the page, under ‘Key Product Impact,’ there are bullets like ‘reduced cart abandonment by redesigning the checkout experience and validating improvements through A/B testing’ and ‘50% reduction in transaction time on the POS.’ Imperfect, but real. No other designer in my stack could have written them about their own work. The fix isn’t asking this candidate to learn a new skill. It’s asking them to apply the skill they’ve already used in one section to the rest of the page.

The ‘partnered with leadership’ bullet, by contrast, could appear word-for-word on every other resume in my stack. And it does. That’s why I stopped reading.

2. The bullet that hedges its own ownership

From another resume in the stack:

‘Helped improve information architecture and navigation across complex platforms used by large user groups.’

Three weak verbs in twelve words. This isn’t a sentence about work. It’s a sentence about being near work.

The problem

This is the bystander bullet. Read the verbs out loud: ‘helped improve.’ ‘Used by.’ That’s it. The writer isn’t the subject of any action. The action — the actual work — is offstage. They’re nearby.

It gets worse when you check the rest of the resume. The same job has four bullets, and three of them lead with hedge verbs: ‘Partnered with cross-functional teams to improve usability…’ ‘Supported front-end implementation through design documentation…’ ‘Helped improve information architecture…’ One job. Three deference verbs. The pattern is the bullet.

Three things produce this.

Modesty trained on the job. Most product designers work in environments that reward “we” over “I.” Stand-ups, retros, Slack channels, every cross-functional ritual is built around the team owning the outcome. That’s healthy for the team and corrosive for the resume. The same designer who’s been told for five years not to take individual credit then sits down to write a resume — a document whose entire job is to take individual credit — and writes “we” energy in third-person clothing. ‘Helped improve.’ ‘Partnered with.’ ‘Supported.’ What the team taught them to say in standup is now what’s on the page.

Junior verbs that didn’t grow up. A first-job designer genuinely does help, support, and contribute — those are accurate descriptions of an early-career role. The verbs travel with the writer as they get promoted. Senior IC, then staff, then principal — and the bullets at each new level still lead with ‘helped’ and ‘supported’ because that’s how they’ve always written about themselves. The vocabulary lags the trajectory. Six years in, the resume reads like a second-year designer’s, and the level signal gets lost.

Risk aversion in print. ‘Helped’ is a verb that cannot be wrong, because it doesn’t really claim anything. ‘Owned’ is a verb that can be wrong — a hiring manager can interrogate it, a former teammate can dispute it. Hedge verbs protect against being challenged on a claim you’re not sure you can defend. They also protect against ever being seriously considered, because the person writing them isn’t telling me anything I can grade.

The candidate may have done plenty of real, decision-making, ship-the-thing work. The bullets are hiding it. Maybe out of modesty. Maybe out of an instinct that taking credit comes across as arrogant. Maybe because the company culture rewarded humility. Doesn’t matter — on a resume, humility reads as absence.

Why does this not resonate with hiring managers

I’m building a candidate stack for a senior IC role. I need to know what level this designer operates at. The verbs are how I do that — or how I would, if they were doing any work.

A designer who owned an IA project says ‘Owned’ or ‘Led’ or ‘Restructured.’ A designer who did the work says ‘Designed’ or ‘Shipped’ or ‘Built.’ A designer who was on the team during an IA project says ‘Helped improve.’ The verbs are the level signal. They tell me whether to slot this candidate at IC4 or IC6 before I’ve read the rest of the line.

When the verbs all hedge, I have two reads:

• The candidate was actually a contributor, not a driver, and the verbs are accurate.

• The candidate was a driver, and the verbs are accidentally torpedoing their level.

Neither read moves them forward. If the first one is true, they’re miscalibrated for the senior role, and I should pass. If the second one is true, they can’t write about their own work clearly, which is itself a senior-designer-level concern, because writing about your own work clearly is the same skill you’ll use briefing partners, presenting to executives, or making a case for headcount. The candidate who can’t claim their own work on a resume is unlikely to claim it in the rooms where it matters, either.

The fix

Pick the verb that exposes the level.

The verb is the level signal — it has to do that work. If the verb is ‘helped,’ it’s signalling a contributor. If it’s ‘restructured,’ it’s signalling a driver. Pick the one that matches the actual seniority of the contribution and let it do its job.

The mechanics:

• Audit every verb on the page. Read the first word of every bullet out loud. If more than one in four is ‘helped,’ ‘supported,’ ‘partnered,’ ‘contributed,’ or ‘participated’ — the resume has a verb problem and a level problem at the same time.

• Pair the verb with the specific artifact. ‘Restructured the navigation taxonomy.’ ‘Owned the redesign of the checkout flow.’ ‘Built the regeneration UI for the AI editor.’ The verb is hollow if the next noun is generic; the specific artifact is what makes the verb defensible.

• If the truest verb is ‘helped’ — cut the bullet. Don’t inflate a real contributor-level activity into a fake driver-level one. Use the space for a bullet you genuinely own. If you don’t have one, that’s information about whether you’re ready for the role.

The bullet that breaks the pattern:

‘Restructured the navigation taxonomy for [the customer-facing platform], consolidating 6 top-level sections to 4 and rebuilding secondary nav around task-based grouping. Cut search-to-find time by 28% across the top 12 user tasks in post-launch usability testing.’

The verb is exposed: ‘restructured.’ Nobody else in my stack could write this about their own work — they’d have to have owned this specific IA project, with these specific numbers, on this specific platform. Even another designer at the same company couldn’t write it, because only one person owned the restructure.

That’s a bullet I can ask four questions about in a screen. ‘Helped improve information architecture across complex platforms’ is not.

3. The bullet with the suspicious number

From a third resume:

‘Conducted user research, journey mapping, wireframing, and prototyping to validate design decisions, increasing conversion rates by 15–30% across client websites.’

It has a number. The number is the problem.

The problem

This is the range stat. When a single number is written as a range — ‘15–30%,’ ‘1–2 minutes,’ ‘35–60%’ — the bullet has already told me what it is. Real measurements come back as single values: ‘23%,’ ‘1m 42s,’ ‘47%.’ A range means one of two things:

• It’s aggregated across many clients, in which case the bullet should specify which clients and the median.

• It’s an approximation — in which case it isn’t a measurement.

This resume does it twice in three lines. Up the page: ‘15–30% across client websites.’ Down the page: ‘reducing bounce rates by 20% and increasing average session duration by 1–2 minutes.’ The 1–2 minutes is the giveaway. No analytics dashboard reports session duration as ‘one to two minutes.’ That’s an instinct, not a number.

Three things produce this.

Generic resume advice, followed without thought. Every “how to write a resume” guide says the same thing: put numbers on your bullets. The advice is correct — quantification is what makes a claim defensible. But the advice gets followed too literally. Candidates know they need numbers, so they add numbers, and the numbers don’t have to mean anything as long as they’re there. The percentage becomes decorative — a signal that says “I know I’m supposed to have numbers here,” not “here’s a result I can defend.”

Aggregation as inflation. Agency-side designers and consultants fall into this category the hardest. When you’ve worked on 25+ client sites, no single number from any one of them is impressive enough to put on a resume on its own. So you aggregate: “across client websites, conversion lifts ranged from 15–30%.” The range is dressed up as scale (“look at all the impact I had across so many projects”). What it actually communicates is “no individual project was strong enough to name.” A bullet about 25 projects is a bullet about no projects.

Methodology stacking to fill the line. ‘Conducted user research, journey mapping, wireframing, and prototyping’ is a list of four things a designer can do. It doesn’t say which one mattered on which project. When the methodology list outpaces the work list, the methodology is doing the bullet’s job for it. The candidate is telling me what tools were in their hands, not what they made with them.

Why does this not resonate with hiring managers

I read the bullets and run the math. Across 25+ websites, conversion lifts spanned a 15-point range — and somehow the candidate measured all of them? Was every site instrumented for conversion before the redesign? Were the redesigns A/B tested or shipped wholesale? Was 15% on one site and 30% on another — or 15% in the first week and 30% by month two? I can’t tell, and the answer changes whether this is a strong bullet or no bullet at all.

A number on a resume is a promise: if you ask me, I can defend it. ‘15–30% across client websites’ is not a promise I can call in. It’s a vibe wearing a percent sign. Worse: the candidate who writes 15–30% is signalling, in advance, that they don’t expect me to ask. They’re expecting me to skim the number and move on. The bullet is calibrated to a screen reader that doesn’t think. I’m the screen reader. I do think.

The level concern compounds this. For a senior product designer interviewing at companies where every shipped feature has clear instrumentation and clear ownership, the range stat reads as a candidate who hasn’t worked in environments where numbers are taken seriously. The number isn’t just unmoored — it’s a tell about the rigour of the work that produced it.

The fix

One project. One number. One baseline.

Pick a bullet you can be cross-examined on. Scale traded for specificity.

The mechanics:

• Trade scale for specificity. A bullet about one project with a defended number outperforms a bullet about twenty-five projects with an undefended range. Pick the project that mattered most, name it, and tell that story. The others can go on the portfolio.

• Anchor every percentage to a denominator. ‘40% conversion lift’ needs the answer to: from what baseline, over what window, and how. ‘From 2.1% to 2.7% (+29%) on 14,000 weekly sessions in a four-week A/B test’ passes the screen. ‘40% conversion lift across client websites’ does not.

• If you have to use a range, name the range’s source. ‘Across the 17 client redesigns I led, conversion lifts ranged from +8% to +34%, with the median at +18%, measured on sites instrumented with the same conversion event’ is a legitimate use of a range. The headline number is now the median, not the spread. That’s an honest use of aggregation.

The bullet that breaks the pattern:

‘Led the redesign of [a specific client’s] e-commerce checkout. Validated a single-page pattern against the existing three-step flow in a 50/50 A/B test over four weeks; the new pattern lifted conversion from 2.1% to 2.7% (+29%) on 14,000 weekly sessions.’

Same activity, same verb, same impact category as the original. But every number is a specific value with an anchor. A hiring manager can ask four follow-up questions about it. The candidate can answer all four. No other designer in my stack worked on this specific client’s checkout flow with these specific numbers — the bullet points back to one person.

If the only number you have is a range, you don’t have a number. You have a guess in a costume.

4. The bullet that’s mostly adjectives

From a fourth resume:

‘Leveraged AI-tools to built scalable, accessible and inclusive design systems ensuring responsive experiences across platforms.’

Count the adjectives: scalable, accessible, inclusive, responsive. Four in one bullet. Count the specific nouns: zero.

The problem

This is the adjective stack. When a bullet has more qualifiers than specifics, the qualifiers are doing the lifting that the specifics should be doing. ‘Scalable, accessible and inclusive design systems’ is six words and says nothing — every design system at every company aspires to be all three. ‘Responsive experiences across platforms’ is what you write when you don’t want to commit to which platforms or what the experiences are.

The pattern shows up across the resume:

• ‘translating blockchain concepts into clear, intuitive flows with beautiful UI’

• ‘a simple user-friendly interface that educated users on advanced trading’

• ‘creating user-friendly, high-performing interfaces’

Strings of admiring qualifiers in the place where a specific noun should sit. The bullet always sounds finished. The work never does.

Three things produce this.

Adjectives as confidence performance. A specific noun makes a specific claim. ‘Onboarding flow with progressive disclosure’ is a thing. ‘Intuitive flow’ is a feeling the reader is being asked to grant you. Designers reach for adjectives when they’re not sure the noun is impressive enough on its own — when they suspect that if they just said ‘I designed the onboarding flow,’ the reader would shrug. So they pad it. ‘Intuitive onboarding flow.’ ‘Beautiful onboarding flow.’ ‘User-centred onboarding flow.’ The adjectives are doing emotional work — trying to make the reader admire the work without describing what makes it admirable. They never do.

The marketing-copy instinct. This is the deeper version of the problem. When a senior designer’s bullets read like product blurbs — strings of admiring adjectives, the kind of language a marketing team writes for a homepage — it tells me the writer is still describing design the way users are supposed to receive it, not the way it actually gets built. Users experience design as ‘intuitive’ and ‘beautiful.’ The designer’s job is to know how those adjectives got there: what the underlying decisions were, what the alternatives were, what the trade-offs cost. The resume should describe the building. It’s describing the user experience instead.

Adjective inflation as a hedge. ‘Scalable, accessible, and inclusive’ isn’t committing to a single property — it’s claiming all three at once, on the theory that nobody can prove any one of them isn’t there. The same hedge logic that produces ‘helped’ as a verb produces the adjective stack: the bullet trying not to be wrong about anything by not really saying anything. The writer is trying to score on three rubric items at once instead of demonstrating one well.

A separate but related issue in the same bullet: ‘leveraged’ is the corporate verb that means ‘used.’ And ‘built’ should be ‘build.’ Small things on their own. But on a senior resume, the cumulative effect is a candidate who didn’t reread the page they’re asking me to read carefully.

Why does this not resonate with hiring managers

When I scan a bullet, I’m hunting for the screen question. ‘Scalable’ isn’t a screen question. Neither is ‘accessible,’ ‘inclusive,’ or ‘responsive.’ All four are aspirations the candidate is claiming — not artifacts they shipped.

A real screen question needs a hook. What was the design system used for? How many components? How many designers consumed it? What was a scalability problem they actually had to solve? An adjective stack denies me all four hooks at once.

There’s a level concern stacked on top. Senior designers are hired to make decisions, not to produce admiring descriptions. When the bullets read like a product page, I assume the writer is still thinking about design from the consumer’s seat — what does the user feel — rather than from the designer’s seat — what trade-offs did I make, what alternatives did I reject, what would the second-best version of this have looked like, and why is the shipped version better. The two seats require different muscles. The bullets tell me which seat they’ve been sitting in.

Adjective stacks also tend to come paired with bullet patterns from the other archetypes — JD voice, bystander verbs, range stats. The problems reinforce each other. By the third bullet, I can already tell I’ll see all four somewhere on the page.

The fix

Replace each adjective with the specific thing it’s trying to describe.

The mechanics:

• Test every adjective. For each qualifier in a bullet, ask: What specific thing am I trying to point at with this word? If the answer is concrete (‘accessible’ = ‘80% of WCAG issues caught before code review’), promote the concrete version into the bullet and cut the adjective. If the answer is vague (‘intuitive’ = ‘I think it felt clean’), cut the adjective and don’t replace it.

• Cut decorative adjectives entirely. ‘Beautiful UI.’ ‘High-performing interfaces.’ ‘Cohesive experience.’ These never earn their place. They’re aesthetic claims you’re asking the reader to grant you without evidence. The reader does not.

• Anchor scope in nouns and numbers, not qualifiers. ‘Design system’ is a noun. ‘Scalable design system’ is a qualified noun. ‘58 components across iOS, Android, and web, consumed by 14 product teams’ is the noun with actual scope. The third version makes the case that the first two were trying to imply.

The bullet that breaks the pattern:

‘Owned the design system for [the product], scaling it from 12 components to 58 across iOS, Android, and web. Established accessibility audit gates that caught 80% of WCAG issues before code review, cutting post-launch accessibility tickets by 60% quarter-over-quarter.’

‘Scalable’ became 12-to-58 across three platforms. ‘Accessible’ became an audit gate with a specific catch rate. ‘Inclusive’ and ‘responsive’ got dropped — they were never doing any work in the first place.

Nobody else in my stack designed this specific system at this scale with this accessibility regime. The bullet points back to one designer. The adjective version points back to a recruiter’s keyword scan.

If your bullet still reads like marketing copy after you’ve revised it, you haven’t revised enough.

5. The bullet that sounds technical

From a fifth resume — seven years in, recently positioning into AI:

‘Established interface behaviors that improved user trust in non-deterministic systems.’

The vocabulary changed. The disease didn’t.

The problem

This is technical-vocabulary cosplay. ‘Non-deterministic systems’ is what ML engineers call models when they’re being precise. A designer using that phrase isn’t being precise — they’re borrowing the language to sound fluent in the system. The result is a bullet where every noun phrase sounds load-bearing and none of them refer to a real thing.

What did they establish? Loading states? Confidence indicators? Stop-generation patterns? Source citations? Streaming behaviour? Edit-after-output flows? Provenance UI? Regeneration affordances? Each of those is a different bullet, and each is interesting. ‘Interface behaviours’ covers all of them and tells me nothing.

‘Improved user trust’ is the second tell. Designers love to claim trust outcomes because trust is fuzzy, and the bar to prove it is wherever you want to put it. Measured how — survey? Decreased re-prompts? Lower abandonment after a bad first generation? Conversion-to-paid after a free trial? Without a specific operationalization, ‘trust’ is the unfalsifiable outcome that lets any work claim victory.

Three things produce this.

The vocabulary is outpacing the work. This is the central mechanism. A designer who has actually shipped streaming UI, stop-generation patterns, and regeneration flows names them, because those are the interesting parts of the job. The vocabulary is specific because the work was specific. A designer who’s read a few AI design blog posts reaches for ‘non-deterministic systems’ because the abstraction does the work the specifics would have done. The vocabulary inflates to fill in for the missing experience.

Career repositioning into the hot category. In the last 18 months, every product designer who can plausibly claim adjacency to AI has rewritten their resume to lead with it. Some of those candidates have actually shipped AI features. Most have used AI tools in their workflow, which is real, but doesn’t make them AI product designers. The bullets blur the line. ‘AI-enhanced analytics dashboard.’ ‘AI-assisted user testing.’ ‘AI-powered usability testing.’ These phrases could mean anything from “I designed the prompt UI for a regeneration flow” to “I used ChatGPT to summarize interview notes.” I can’t tell which. The candidate is hoping I don’t ask.

The fuzzy outcome that can’t be cross-examined. ‘Improved user trust’ is the AI-era cousin of ‘improved usability’ and ‘enhanced engagement.’ All three claim a category of outcome without committing to a measurement. They’re built to survive scrutiny: if I ask “how did you measure that?”, the candidate has time to invent something plausible. A specific outcome (‘reduced abandonment after a failed first generation from 41% to 18%’) is a number the candidate has to know in advance. The fuzzy outcome is for candidates who don’t.

Why does this not resonate with hiring managers

I’m hiring for AI design right now. I see a lot of these. The bullet pattern-matches against every other resume from a designer who switched into AI in the last 18 months. I have no way to triage: did this person actually ship a regeneration flow that handled hallucination gracefully, or did they recolor the chatbot’s avatar?

There’s a working theory I apply when reading these. When the technical vocabulary outpaces the specific work, the work probably didn’t require the vocabulary. A designer who has shipped real AI interaction work names the specific failure modes, UX patterns, and edge cases. A designer who hasn’t reaches for abstraction. The vocabulary level is itself a tell.

And it falls apart in a screen. If I bring them in and ask, “Tell me about a failure mode you designed for in the AI tool,” I need to hear something concrete — streaming interruptions, source attribution under low confidence, the UX of a model refusing to respond, the difference between regeneration and edit. If the answer is more ‘non-deterministic systems’ and ‘user trust,’ the screen is over. The vocabulary held up on paper. The work won’t hold up in a room.

The candidate may have done real AI work. The bullet has the same texture as the bullets from candidates who haven’t, and I can’t distinguish without spending 30 minutes on a screen. The cost of that wasted screen, multiplied across the seven other AI-cosplay resumes in the stack, is the budget I don’t have. So I cut.

The fix

Name the failure mode. Name the AI UX pattern. Name the metric.

The mechanics:

• Pick the specific AI design problem you actually solved. Was it the regeneration flow? Stop-generation? Source citations under low model confidence? The interaction model between user edits and model output? Pick one. Name it. The specificity is what proves you’ve done the work, because somebody who hasn’t done the work doesn’t know these are the design problems.

• Operationalize ‘trust’ before you claim it. If you measured trust, say how. NPS shift? Decreased rage-clicks on regenerate? Increased acceptance of model output without editing? If you didn’t measure it, don’t claim it. Claim the thing you measured.

• Date the AI claim correctly. If you started shipping AI-feature design in 2024, the bullet starts in 2024. Don’t retroactively AI-ify a 2021 role — the chronology won’t hold up in a screen, and a hiring manager who’s hiring for AI is paying attention to chronology.

The bullet that breaks the pattern:

‘Designed the regeneration and stop-generation UI for an AI content tool — including streaming feedback, partial-edit handoff, and an inline confidence indicator. Cut abandonment after a failed first generation from 41% to 18% over six weeks of iteration.’

That bullet says: I know what an AI tool’s failure modes are. I designed it for them. I have a number that survives a follow-up question. No other designer in my stack worked on this specific regeneration flow, this specific failure mode, or this specific drop in abandonment. The bullet points back to one designer.

The ‘non-deterministic systems’ version says: I read the term in a Notion doc.

The kicker: none of the applicants were a fit

Here’s the thing I haven’t told you about the bullets I’ve been dissecting.

They were all applying for the same job. Senior Product Designer — Mobile.

Take a second with that. Now scroll back up through the bullets I’ve pulled apart. Notice anything?

The word ‘mobile’ barely appears. When it does, it’s an adjective in a list — ‘web and mobile platforms,’ ‘responsive, mobile-first experiences,’ ‘Mobile (iOS/Android)’ tucked into a skills line. Never the subject of a sentence. Never the substance.

Not one bullet about a mobile-specific design problem did any of them actually solve. Not one bullet about an iOS gesture pattern, a Material vs Human Interface Guidelines decision, an App Store onboarding flow, a tab-bar vs bottom-sheet architecture call, a mobile performance constraint that shaped a UI choice, a native vs hybrid trade-off, any of them weighed. Not one bullet about the difference between designing for a 6-inch screen held in the hand and a 27-inch screen with a cursor.

One candidate mentioned mobile twice — ‘crypto mobile app, 90K users’ and ‘crypto mobile app at [previous company].’ Mobile used as a noun, twice. No depth. No mobile-specific decisions described. Just the platform name, used as a tag.

These resumes weren’t aiming at this job. They were aiming at a job. Senior Product Designer, generic. ‘Mobile’ in the title got noted by the ATS and then ignored by the candidate.

This is what generic bullets cost you on top of the readability problem. A vague bullet doesn’t just blur you into the other candidates — it makes you unable to argue for a specific role. If your resume reads the same to every hiring manager looking at every JD, then your resume hasn’t said anything to any of them.

The five archetypes above are the mechanics. The mobile gap is the consequence. If your bullets are written generically — JD voice, bystander verbs, range stats, adjective stacks, technical-vocabulary cosplay — there’s no slot in any of them to make the case for the specific role you applied for. The bullet that would make that case got crowded out by the bullet that could appear on anyone’s resume.

The fix isn’t ‘make your bullets more specific in general.’ It’s ‘make your bullets specific to the role you want.’ If you’re applying for a mobile role, mobile work is the load-bearing center of the page. Not in the skills section. Not in a passing ‘responsive design’ mention. In the bullets, where the case actually gets made.

Eight applicants for Senior Mobile. Zero of them made the case for it.

Your resume is the only place you get to argue that this specific job should go to you. Generic bullets don’t make that argument. They don’t try. They describe a candidate. They don’t introduce one. The 17th resume doesn't get the screen. It gets the stack.