How to hire a UX designer

First, are you hiring a UX designer or a product designer?

At most companies below a few hundred people these are the same job with different titles, and treating them as different is how a role ends up with a job description nobody can satisfy.

Where the distinction is real, it comes down to where the person sits relative to the decision about what to build. A UX designer, strictly, owns whether the thing is usable and coherent — flows, information architecture, interaction, the research that informs them. A product designer owns whether it should exist in that shape at all, and is expected to argue about scope with the people who set it.

The practical question that settles it: when the roadmap is wrong, is this person expected to say so? If yes, you are hiring a product designer regardless of what the title says, and you should assess for the argument as well as the craft.

What a portfolio can and cannot tell you

A portfolio is good evidence of craft — visual judgment, systems thinking, whether someone can hold a complex flow together. Look at it for that, and trust it for that.

What it cannot show is the shape of the decisions. Every case study is a story about a choice that was made, told after it worked out, usually by someone who was one of six people in the room. The four options that were rejected are not in there, the constraint that changed in week three is not in there, and the version where the whole thing got cancelled never becomes a case study at all.

Since 2024 there is a second problem. A convincing case study — the structure, the narrative, the process artefacts, the writing — can be generated by someone who has never run a project. The craft in the screens is still real signal. The story around them is not, and reading the story more carefully does not fix it.

The three things to assess instead

Each of these is answerable in a conversation or a written situation, and none of them is answerable from a CV.

• What they questioned. Give them a brief with something wrong in it — a stated solution that does not follow from the stated problem — and see whether they build it or ask about it. The strong ones ask before anything else; it is the most reliable single signal in the whole process.
• What they cut. Describe a scope that will not fit the date and ask what goes. Watch whether they cut the thing that is hardest to build or the thing that matters least, and whether they can say why in one sentence.
• What they refuse. Ask what they have pushed back on and lost. A designer with no examples has either never had a real constraint or does not push back, and both are worth knowing before you hire.

A process that fits a team without a design lead

The hardest version of this problem is hiring your first or second designer when nobody on the team can evaluate design work. The instinct is to hire a consultant to review portfolios; the cheaper move is to change what you are evaluating.

You cannot judge whether a flow is well constructed. You can absolutely judge whether someone's reasoning about a trade-off is sound, because that is a general skill and you use it every day. So put the weight there: give every candidate the same badly-specified brief, and score how they handled the specification rather than what they produced.

Then use your one expert judgment carefully. One paid hour with a senior designer you trust, looking at the two finalists' actual work, is worth more than five hours of the same person helping you write a job description.

What to pay attention to in the interview

Two questions do most of the work, and both are about specificity rather than opinion.

«Tell me about a decision on this project that you now think was wrong.» A designer who has shipped anything has several. One who describes a mistake that was somebody else's, or a mistake that turned out fine, is telling you how they will handle being wrong on your team.

«What did you want to do that you did not get to do?» This surfaces the constraint they actually operated under, which is the part every case study leaves out. It also tells you whether they can lose an argument and keep working, which is most of the job at any company with more than one opinion in it.

Frequently asked

What is the difference between a UX designer and a product designer?

At most companies, nothing but the title. Where it is real, the difference is ownership of the question of what to build: a UX designer owns whether it is usable and coherent, a product designer is expected to argue about whether it should exist in that shape. Hire by which of those decisions you need made, not by the word in the job ad.

Should I ask for a portfolio at all?

Yes, for craft. Just stop treating the case study narrative as evidence of how the person works — it is a story told after the fact by one of several contributors, and it can now be generated wholesale. Look at the screens, not the story.

How do I hire a UX designer with no designers on the team?

Shift the weight of your process onto reasoning about trade-offs, which you can evaluate without design expertise, and buy exactly one hour of a senior designer's time to look at the final two candidates' actual work. Judging the reasoning is a general skill; judging the craft is not, and paying for the part you cannot do is cheaper than guessing at all of it.

Is a take-home the right way to test a UX designer?

Only if it is capped hard, identical for everyone, and scored against a rubric you wrote first. Otherwise it measures who had a free weekend — and your strongest candidates, the ones with three live processes, are the ones who decline.