In short
Choose a product designer who can turn an ambiguous problem into clear workflows, rules, states, and testable decisions; work with real content and data; explain trade-offs; collaborate closely with engineering; and show what evidence changed their design. A polished portfolio is necessary evidence of craft, but not proof of product judgement.
Ask for one case in depth
Have the designer explain:
- original problem and evidence;
- their exact responsibility;
- users, constraints, and business rules;
- alternatives considered;
- difficult states and edge cases;
- what research changed;
- engineering collaboration;
- result and attribution limits;
- what they would change now.
One honest case reveals more than ten unexplained screens.
Evaluate seven capabilities
Problem framing
Can they separate a request from the underlying user and business problem?
Workflow and systems thinking
Do they model roles, data, permissions, state transitions, errors, and operations—not only happy-path pages?
Research judgement
Can they choose a proportionate method, observe behaviour, separate evidence from preference, and make a decision from it?
Interaction and visual craft
Are hierarchy, typography, content, responsive behaviour, and interaction precise enough to reduce user effort?
Accessibility
Do they consider keyboard, focus, labels, errors, contrast, zoom, motion, and semantic implementation throughout the system?
Engineering collaboration
Can they discuss feasibility early, adjust without losing intent, specify important behaviour, and review production rather than throwing over files?
Product judgement
Can they decide what should not be built, distinguish core value from breadth, and explain the consequence of a trade-off?
Use a bounded paid exercise
If more evidence is required, use a small real problem with existing context, compensate the candidate, limit time, and review reasoning together. Do not ask for free speculative redesigns of the company's product.
Portfolio red flags
- no explanation of personal contribution;
- only polished happy paths;
- invented metrics or unsupported attribution;
- research listed but not connected to decisions;
- no content, data, error, or responsive states;
- engineering described as a handoff;
- every case follows the same fashionable visual style.
Interview questions
- Which assumption was most dangerous?
- What did you remove from scope?
- Show a rule or state that changed the interface.
- What did engineering change in your thinking?
- Which evidence contradicted the team?
- How did you test accessibility?
- What happened after launch?
- Which decision would you reverse?
Common questions
Should a product designer be able to code?
Not necessarily. They should understand implementation constraints, component systems, responsive behaviour, semantics, and how to collaborate with engineers.
How is a product designer different from a UI designer?
A product designer usually owns broader problem framing, workflows, states, research, and product trade-offs; a UI designer may focus more deeply on interface and visual execution.
Is industry experience required?
Only when domain rules are unusually consequential. Evidence of learning complex domains and working with experts can be more valuable than superficial sector familiarity.
Should I give a design test?
Use a compensated, bounded exercise only when portfolio and interview evidence are insufficient. Review reasoning rather than expecting finished unpaid work.
What should the contract or offer clarify?
Scope, collaboration, source files, intellectual-property terms, confidentiality, research access, tools, review expectations, and implementation involvement.
