Hire a product designer who fits your team
Fifteen minutes of real work situations, with no right or wrong answers. You see how each designer questions a brief, what they cut under pressure and how they like to work, next to the profile your team needs.
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 with a request
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.
The CEO: “We need a guided onboarding with tooltips. I saw it at a competitor and it works.”
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
Situations a product designer runs into
Twelve short situations like this one, drawn from the day-to-day work of the role. The live ones 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.
A recommendation for your product designer role
You mark what this job can’t do without. The report opens with a clear call for it, shows where the candidate stands on each capability you chose, and gives you three questions for the interview.
Marta R. · Product Designer
Leads with both of the things you named
Of what 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.
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 the same situations for every candidate, read against what you said this role needs. | 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. |
From open role to shortlist
Choose the role, what it should lead with and how your team works. It takes about ninety seconds.
Send it to each candidate or paste it in your job ad. There’s nothing to install and nothing to schedule.
Short, varied situations from the day-to-day of the role. No right or wrong answers, about fifteen minutes, on any device.
The report is ready when they finish: how close each person is to your profile, and questions for the interview.
New link
Other product roles
One credit per candidate, spent only when they start. The first is free (see what the packs cost), and nothing expires.
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. From one sitting, the same designer can fit a founder's first hire and not a large product team, or the other way round.
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.
Read these before you decide
8 min read
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 read
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 read
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
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.