Designer interviews are less about tools and more about process: how you research, how you justify decisions, and how you work with constraints. Below are the most common questions with model answers.
Every question comes with a model answer you can compare yours against.
Start by understanding the problem and success criteria, not the requested solution — a brief asking for a dashboard often hides a question about a single number. Then research existing behaviour and constraints, sketch several directions broadly before refining one, prototype at the fidelity the question requires, test with users, and iterate. Handoff and post-launch measurement are part of the process, not afterthoughts.
UX is the whole experience of achieving a goal — structure, flow, and whether the thing solves the problem. UI is the visual and interactive layer through which that happens. A beautifully designed subscription screen where cancelling requires an email to support is excellent UI and hostile UX; conversely a plain, ugly form that gets you through in ten seconds is good UX with poor UI.
Give participants realistic tasks rather than asking their opinion, observe silently, and resist explaining the interface — the moment you help, the data is gone. Five participants per user group typically reveal most severe issues, and testing more usually returns the same findings; it is better to run several small rounds between iterations than one large study at the end.
A design system is a shared library of components, tokens, and usage rules that keeps a product consistent as more people work on it. It saves the recurring cost of redesigning a button and lets designers spend time on actual problems. It only survives if it has an owner and a contribution process — an unmaintained system becomes a museum that everyone works around.
Separate preference from evidence: ask what outcome they are worried about, then respond with research, usage data, or a heuristic principle rather than taste. If the disagreement stands and the data is thin, propose a test rather than winning the argument. Being able to say what would change your mind makes you far more persuasive than defending the work.
Accessibility means people with disabilities can use the product. The baseline is 4.5:1 contrast for body text, never conveying meaning by colour alone, full keyboard operability with a visible focus state, correct semantic structure and labels for screen readers, and text that reflows when zoomed to 200 percent. These also improve usability for everyone, which is the argument that usually wins budget.
A handoff includes states, not just screens: empty, loading, error, and edge cases like a very long name or zero results. It covers responsive behaviour, interaction and motion specifics, and which design-system components are used. The best predictor of a smooth handoff is that developers saw the work in progress — a handoff that is the first conversation is already late.
Establish what the constraint actually is — usually effort, technical limitation, or timing — and find which part of the value survives at lower cost. Ship the reduced version deliberately, document what was cut and why, and agree on what would trigger revisiting it. Designers who treat constraints as part of the problem rather than an obstacle get far more of their work built.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a UI/UX Designer interview →