Product designer design interview questions

As asked

Pick a checkout flow on any product you use that you think is bad. Walk me through how you would redesign it.

Sample answer outline

Name the product and the specific user. State your hypothesis about what is wrong (friction at a specific step, unclear errors, hidden costs, broken keyboard navigation). Walk through the current flow, calling out each problem with a reason. Sketch the redesign at the right fidelity for the conversation, and explain the principle behind each change (reduce decisions, surface costs early, default to the common case). Discuss what you would A/B test to validate, what could backfire, and what success looks like. Strong designers are opinionated but show their work.

Expect these follow-ups

• Which change would you ship first and why?
• What would tell you the redesign is worse?
• Who on the team would push back, and how would you handle it?

As asked

Your PM asks 'should we add a dark mode?' How do you answer that with research? What method would you choose and why?

Sample answer outline

First, sharpen the question: dark mode is a means, not an end. Are we trying to reduce eye strain, match OS preference, hit a feature parity bar, or differentiate? Each leads to a different research method. Quantitative options: usage of competitors with dark mode, support tickets requesting it, survey of users who churned. Qualitative: 5 to 8 user interviews to understand when and where they would use it. Combine: if survey says 60 percent want it but interviews show casual interest, the willingness-to-pay is shallow. Method depends on the decision the research will inform.

Expect these follow-ups

• When would you reach for a diary study?
• How do you handle a leading PM who has already decided?
• What is your sample size for qualitative research?

As asked

You join a startup with 40 engineers and no design system. The UI is inconsistent. Walk me through how you would build a design system in 6 months.

Sample answer outline

Audit first: screenshot the existing UI, identify the components that repeat (buttons, inputs, modals, cards) and the patterns that diverge. Pick the 10 to 15 highest-value components to start with. Establish the foundations: a token system (colour, spacing, type, radius, shadow) that engineers can pull into Tailwind config or CSS variables. Build the first batch of components with one engineer pair, ship them into one product surface, iterate from real usage. Documentation matters: Storybook plus do/don't usage notes. Treat the design system as a product, with a roadmap, contributions, and a versioning story.

Expect these follow-ups

• How do you handle the legacy UI that does not use the system?
• Who owns the design system long-term, design or engineering?
• When does Tailwind or shadcn/ui replace a custom system?

As asked

Walk me through how you would run an accessibility audit on a web app. What do you check, and how do you prioritise the findings?

Sample answer outline

Automated first: axe DevTools or Lighthouse for the obvious wins (missing labels, contrast, semantic HTML). Manual next: keyboard navigation through every primary flow without a mouse, screen reader pass with VoiceOver or NVDA on the highest-traffic pages, zoom to 200 percent and check responsive behaviour. Test with users who rely on assistive tech, not just simulated. Prioritise by WCAG severity and traffic: critical paths on top, decorative issues last. Report findings with screenshots, the specific WCAG criterion, the user impact, and a suggested fix. Track to remediation, do not just file and forget.

Expect these follow-ups

• What is the biggest a11y mistake even careful teams make?
• How do you embed a11y into the design and review process so audits find less?
• When is a custom component cheaper than fixing the native equivalent?

As asked

Walk me through how you design the empty, loading, and error states for a new feature. What goes wrong when teams skip these?

Sample answer outline

Empty state: explain what the feature is for, what the user should do next, and remove ambiguity about whether something is broken or just unused. Use a clear call to action. Loading state: skeleton over spinner where possible to reduce perceived latency; reserve layout space to prevent layout shift. Error state: human language, specific to the failure, with a recovery path (retry, go back, contact support). Skipping these is the most common reason features feel broken on day 1. Treat the empty state as the marketing copy for the feature, not an afterthought.

Expect these follow-ups

• When is a spinner better than a skeleton?
• How do you write error copy without sounding patronising?
• What is the difference between a loading state and a stale-data state?

As asked

Critique the multiplayer cursor feature in Figma. What works, what does not, and how would you improve it?

Sample answer outline

What works: presence is felt without being intrusive, the named labels orient you to who is where, the colour assignment is consistent within a session. What gets noisy: many cursors in a small area create visual clutter, the labels can occlude content, idle cursors stick around. Improvements to consider: fade idle cursors, cluster cursors in dense areas with a count badge, give the user a way to mute presence on a layer. Strong design critique cites the principles (presence, focus, control) and proposes concrete changes, not just opinions.

Expect these follow-ups

• How would this change in VR or AR?
• How do you balance presence and focus in collaborative tools?
• When is presence the wrong default?

As asked

When do you build a low-fidelity prototype, a high-fidelity Figma prototype, or a coded prototype? Walk me through the decision.

Sample answer outline

Low-fi (paper, rough Figma): for early concept testing where you want feedback on the idea not the polish. Cheap to throw away. High-fi Figma prototype: for usability testing of a near-final flow, executive review, or design handoff. Looks like the product, behaves close to it. Coded prototype: when the design depends on interaction physics (drag, animation, real data shape) or you need to test on real device performance. More expensive but uncovers issues no Figma prototype can. Rule of thumb: match fidelity to the question, not to the audience.

Expect these follow-ups

• When does a Figma prototype mislead you about feasibility?
• How would you decide when to invest in a coded prototype?
• What is the most useful prototype you ever built?

As asked

Walk me through how you hand off a design to engineering. What artifacts, what conversations, and what goes wrong?

Sample answer outline

Hand off is a process, not a single moment. Engineers should be in the design review before the design is final so they catch infeasibility early. The artifact: a Figma file with components named to match the design system, states (loading, empty, error, hover, focus), interaction notes, and any motion specs. Document the why behind decisions inline. Pair-review the build during implementation, not just at the end. The handoff fails when designers throw screens over the wall and discover during QA that the design system tokens were ignored or the empty state was never built.

Expect these follow-ups

• How do you handle a designer who never engages with engineering?
• What is your responsibility when the build does not match the design?
• When does spec writing become wasteful?

As asked

A user's card payment fails at checkout. What should the error message say, and how do you decide what not to say?

Sample answer outline

A good answer is clear, specific where the system knows the cause, and action-oriented without blaming the user. It should distinguish between insufficient funds, expired card, network failure, and unknown decline only if the payment processor safely exposes that reason. Avoid exposing sensitive bank details or implying certainty the product does not have. The message needs a recovery path such as trying another card, checking details, or contacting the bank. Strong UX writers also mention localisation, accessibility, and consistency with the product voice.

Expect these follow-ups

• How would you write the same message for a screen reader user?
• What if legal says you cannot disclose the decline reason?
• How do you test whether the copy reduces support tickets?

As asked

A mobile app moves users from a list of cards to a detailed view. How would you design motion that helps comprehension rather than just looking polished?

Sample answer outline

Use motion to preserve object continuity: the selected card can expand or hand off into the detail surface so users understand where they went. Keep timing short, easing natural, and hierarchy clear so the transition does not delay the task. Define what moves, what fades, and what remains stable, then specify behaviour for interruption and back navigation. Respect reduced-motion settings with an alternate transition that preserves orientation without large movement. Candidates who talk only about delight miss the core product motion goal: reducing cognitive load.

Expect these follow-ups

• How would you specify this for iOS, Android, and web engineers?
• What changes for a low-end device?
• How do you decide whether the motion is too slow?