Hiring Designers: Process, Portfolio, and Take-Home Tests
How to hire UX designers with structured interviews, a well-scoped test, and a portfolio read with criteria, following Nielsen Norman Group's recommendations.
What does it mean to hire well?
Hiring well is not choosing the person with the nicest portfolio. It is reducing the chance of a mistake by comparing every candidate against the same measure. According to Nielsen Norman Group, how well a hiring interview works depends on how much structure it has. Without structure, each interviewer asks what interests them and decides by intuition.
The process has three parts to design before you post the role: which skills matter for the job, which questions you ask, and what a good answer looks like. Before hiring, it helps to know which roles the team needs, which is what the article on building a UX team explains. Once the person arrives, the onboarding process is the first real test of the decision.
Why does this matter for a junior designer?
Because if you ever sit on a hiring panel, your evaluation will count just as much as everyone else’s. A junior who understands how a candidate is measured also knows how to prepare their own: what to show, what to explain, and what to ask.
The way a team hires also shapes how it feels for months. A long, unfair, or confusing process pushes good candidates away and leaves a bad impression on the people already working there.
How do you design a structured process?
Nielsen Norman Group proposes a concrete sequence:
- Analyze the role. List the real tasks of the job. The NN/g article suggests starting with about 25 to 35 tasks and narrowing them to 10 or 20 that matter most.
- Write fixed questions. Use behavioral questions (what did you do in a past situation) and situational questions (what would you do here). Every candidate answers the same ones, in the same order.
- Define what a good answer looks like. For each question, write at least three examples of a very good answer and three of a very poor one. That way the rubric stops depending on the interviewer’s mood.
- Form a panel. NN/g recommends three or four interviewers, each meeting every candidate in an individual one-hour session.
- Hold a short, early debrief. A meeting of about 30 minutes with all interviewers within 24 hours, where each person shares what they noted.
The most important rule: do not compare candidates until you have finished all the interviews. Comparing early lets the first candidate you saw set the benchmark for everyone else.
What about the portfolio?
A portfolio shows work, but not always who did it. NN/g says portfolios do not always give an accurate appraisal of individual contributions, because of widely available templates and because UX work is collaborative. In NN/g’s survey, respondents reported struggling to discern a candidate’s specific contributions or process on team projects.
To read a portfolio with judgment, ask about the individual role in each case:
- Which decisions did you make yourself, and which were made by the team?
- What changed after the user test or the delivery?
- What would you do differently if you had to redo it?
The answers to these questions say more than the screenshots. If you are building your own portfolio, see building a UX portfolio. The article on portfolios with AI projects covers a specific version of this problem, in case your work includes AI.
When is a practical test worth it?
NN/g considers exercises, whether take-home or on a whiteboard, a better way to show individual skills, and says they can be evaluated fairly across candidates. It also acknowledges that they are unpopular with interviewees. The cost is real:
- On a whiteboard, the exercise adds stress and may measure pressure more than skill.
- Take-home, it adds a workload that not everyone can take on.
In its article on hiring insights, NN/g quotes an interviewee who says that for every hour the hiring manager spends evaluating a candidate, the candidate may spend about 30 hours. They admit the figure may be extreme, though they put the ratio at more than 10 to 1. The practical takeaway: scope the test to what you really need to see, and write the rubric before you send it.
When should you NOT use a test?
- When it is so long that only people with free time can do it, because it penalizes candidates who work or care for others.
- When there is no rubric. A test without evaluation criteria only measures the taste of whoever grades it.
- When the candidate has no way to do it well, for lack of product context or tools.
In these cases, a structured interview built around real past work can give an equally good signal at lower cost.
Example
Illustrative example: a company hires a senior product designer.
- Role analysis: from 30 tasks, it keeps 12, including “define a flow for a new user” and “work with engineering on prioritization”.
- Questions: “Tell us about a project where you had to change scope with little time” and “What would you do if a user test contradicts what the business asked for?”
- Rubric: for the second question, a very good answer cites data, consults the business, and proposes a follow-up test. A very poor answer decides without data or ignores the test.
- Panel: four interviewers, each with their own notes from the interview.
The result does not guarantee a good hire, but it removes many of the reasons hiring goes wrong.
Common mistakes
- Asking each candidate different questions, or riddles that say nothing about the job.
- Deciding on a “I like them” or “I don’t like them” with no notes or justification.
- Comparing candidates before the interviews are finished.
- Handing everything to HR and giving interviewers little training on design.
- Assigning a long test without explaining how it will be evaluated.
- Letting similarity bias decide: hiring the person who resembles the interviewer.
Sources
- Nielsen Norman Group, Structured Hiring Interviews
- Nielsen Norman Group, Hiring and Retaining UX Teams
- Nielsen Norman Group, UX Hiring Insights