Prototyping interview questions
Prototyping questions a UX / UI designer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
You want to know whether people can find the export button. What do you prototype?
The strongest answer: The least that answers it — grey boxes with real labels and one working path — because the question is about finding and naming, not about colour or motion
Why it works: Right — the question sets the fidelity; extra polish buys you feedback about polish.
- The question sets the fidelity.
- Real labels, fake styling.
- Build only the path you test.
- Polish invites polish feedback.
You are specifying one button. Which states do you hand over?
The strongest answer: Default, hover, focus, pressed, disabled and loading — and what disabled means here, because a control that does nothing with no explanation is a dead end
Why it works: Exactly — and focus is not optional: it is the only state a keyboard user can see.
- Six states for every control.
- Default, hover, focus, pressed.
- Disabled and loading too.
- Say what disabled means here.
A reviewer asks you to “add some nice animation” to the panel that slides in.
What do you do?
The strongest answer: Give the motion a job — show where the panel came from and where it goes back to — keep it short, and check the flow still works with reduced motion turned on
Why it works: Right — motion explains a change of place or state; motion that explains nothing is a delay.
- Motion must explain something.
- Show origin and destination.
- Keep it short and interruptible.
- Respect reduced motion.
When is a clickable prototype the wrong next step?
The strongest answer: When the question is still “what job is this?” — a click-path will freeze a guess
Why it works: Exactly. Match the artefact to the question. Always-prototype is busywork. (The third option is actually close — conversation can be right.)
- Prototype when the question needs a path.
- Do not freeze a job-guess in clicks.
- A conversation can be the prototype.
- Do not prototype to look busy.
A prototype tested beautifully; the built feature is getting complaints.
What did the prototype hide?
The strongest answer: Real data and real waiting — long names, empty accounts, permissions, slow networks, failures — the prototype ran a clean path on content that was chosen to fit
Why it works: Exactly — a prototype tests comprehension and flow, never latency, data shape or permissions.
- Prototypes test understanding, not reality.
- Retest with real data.
- Include waits, errors and permissions.
- Spec what the prototype could not show.
The team has been through four prototype rounds and the debate has stopped moving.
When do you stop prototyping and ship a thin slice instead?
The strongest answer: When the open questions need real data, load or money to answer — then I ship the smallest honest slice behind a flag, with a way to watch it and to roll back
Why it works: Right — name what a prototype physically cannot answer, then take the cheapest real test with a way out.
- Stop when the method runs out.
- List the open questions.
- Ask which need reality.
- Ship a small, reversible slice.