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 can’t 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
The CEO: “We need a guided onboarding with tooltips. I saw it at a competitor and it works.”
Every case opens with a request that already contains its own answer, because that’s 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's 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
The kind of call they make
Situations a product designer runs into
Twelve short situations like this one, drawn from the day-to-day work of the role. The live situations are confidential, because an assessment you can rehearse stops measuring anything.
Example situation
You're three weeks into a redesign of the checkout flow. The CEO forwards you a competitor's onboarding and asks for the same guided tooltips, this Friday.
What you get
A recommendation for your product designer role
You mark what this particular job can’t do without. The report opens with a clear call for that job, shows where the candidate stands on each capability you chose, and gives you three questions to ask in the interview.
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.
Why these matter for a product designer
- Spots when the brief is wrong
- The single most expensive thing a product designer gets wrong. A designer who builds exactly what was asked for, beautifully, can burn a quarter on a feature that was never going to move anything.
- Sweats states and edge cases
- Empty, error, loading, offline, and the row with a name forty characters long. It's the difference between a design that survives contact with real data and one that engineering has to finish inventing.
- Holds a position with a senior stakeholder
- Caving on the first push is expensive; so is digging in when the constraint they were given is legitimate. Good designers know which situation they're in.
Against what you already do
What each format sees, and what it misses
| Format | What it shows you | What it misses |
|---|---|---|
| Portfolio review | Craft, taste, and whether they can tell the story of a project. For a visual role this is solid evidence, and it's the fastest signal you'll get. | Who decided what. A case study is written after the fact by the person being assessed, and the parts that would tell you most (the brief they were handed, the idea that got killed) are the parts nobody publishes. |
| Take-home exercise | How they work when nothing is watching, and what they consider finished. | How they decide under a real constraint. A take-home has no stakeholder changing their mind on day three, no engineer saying the timeline halved, and no way to tell whether they spent four hours on it or forty. |
| Portfolio walkthrough interview | Whether they can hold a conversation about their own work and think out loud. | A comparable answer. Every candidate gets a different project, a different set of follow-up questions and a different interviewer mood, so at the end you have six impressions and nothing you can line up side by side. |
| This assessment | How they decide, on twelve situations every candidate answers identically, scored against the capabilities you named as essential for this role. | Craft. It won't tell you whether they can draw; the portfolio covers that. The two answer different questions, and a sensible process uses both. |
How it works
Three steps,
with no calls and no setup
What must they be good at?
- Spots 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.
Questions
Assessing product designers, in practice
No. A portfolio shows craft and this shows judgment. They're different questions, and a good process asks both. What it does replace, for most teams, is the unpaid take-home: it takes fifteen minutes instead of six hours, and every candidate answers the same thing.
About fifteen minutes, on any device, whenever suits them. There's nothing to install and no scheduling. The report reaches you the moment they finish.
They can try, and it helps them very little. There's nothing to write or polish, and a model can't know what this particular person would do. Read past the headline.
No. You describe what the role can't do without before you send the link, and the report is read against that. A designer scored for a founder's first hire and for a large product team gets two different recommendations from one sitting.
A recommendation, where the candidate stands on each capability you named, and three questions worth asking them in the interview. It's written to be read in about four minutes and forwarded to a hiring panel.
One credit per candidate, spent only when they start. The first candidate is free with no card. Credits don't expire, so a role you put on hold costs nothing.
Related reading
Read these 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 can't 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 shouldn't 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 doesn't answer whether they should have. That comes down to 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're shipping with. Those decisions 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 shouldn't 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 choose to take on. A GitHub profile shows what they merged. Most of this role's value sits in what never got built.
Read it