15 minutes, report the moment they finish
Product designer skills assessment
Twelve written situations, about fifteen minutes, that measure how a product designer decides: whether they question a brief, what they cut under pressure, and what they refuse to do. Scored against the capabilities you name as essential for your role.
The gap
What you cannot see when you hire a product designer
A portfolio shows the final screens. It never shows what the brief said before they fixed it, what they argued for and lost, or what they cut when the deadline moved.
The case starts here
“We need a guided onboarding with tooltips. I saw it at a competitor and it works.” — the CEO
Every case opens with a request that already contains its own answer — because that is how requests arrive at work. What we measure starts with whether they notice.
What this case shows you
- Whether they accept the brief or ask what outcome it is meant to move
- What they ask before designing anything
- What they cut when six weeks of engineering disappear
- Whether they have a second idea when the obvious one is ruled out
- Whether they can name the weakest part of their own proposal
Scoring
The same six capabilities, every role
The case changes. The rubric does not. That is what makes a product designer comparable to another product designer, and a score meaningful across your whole shortlist.
- Spots when the brief is wrong
- Knows what the data supports
- Sweats states and edge cases
- Knows what is cheap to build
- Explains decisions outside the team
- Holds a position with a senior stakeholder
- Moves without being told
- Keeps going when the plan changes
Marta R. · Product Designer
Leads with both of the things you named
Reaches first for spots when the brief is wrong. The distance here is not capability, it is how your team works.
How much of their attention this one gets — not a pass mark.
How it works
Three steps.
No calls, no setup.
What must they be good at?
- Spot when the brief is wrong
- Knows what the data supports
- Moves without being told
- Sweats states and edge cases
One credit per candidate, spent only when they start. The first is free — see what the packs cost — and nothing expires, so a role on hold costs nothing.
Related reading
Worth reading before you decide
8 min
How to evaluate a UX researcher
Evaluate a UX researcher on what they refuse to conclude: whether they reframe a question that cannot be answered, whether the method follows the decision rather than the budget, how they spot a flawed study and say so, and how they deliver a finding nobody wants. A portfolio shows conclusions that survived. It never shows the studies that should not have been run.
Read it8 min
How to evaluate a frontend engineer beyond the coding test
A coding test answers whether someone can build it. It does not answer whether they should have — whether they spot the states a design forgot, how they respond to a spec that breaks at scale, what they cut when the date moves, and whether they name the risk they are shipping with. Those are the decisions that make a frontend hire expensive or excellent, and none of them appear in an algorithm exercise.
Read it8 min
How to evaluate a design engineer
Evaluate a design engineer on the decisions nobody logs: when a component should be new, a variant, or should not exist at all; how they trade system consistency against shipping this week; what they do with a design that ignores the system; and which debt they take on purpose. A GitHub profile shows what they merged. The value of this role is largely in what never got built.
Read it
Hiring a product designer right now?
Invite one candidate and read their report the moment they finish. The first one is free, with no card.