12 product design interview questions and how to answer them

A good portfolio gets you the call. The interview decides whether you get the job, and it rarely asks you to draw anything. It describes a messy product situation and watches how you think.

Product design interviews test judgment: how you find the real problem, weigh trade-offs, handle disagreement and tie a design choice to a result. Polished screens help, but the strongest answers are about reasoning. Below are twelve scenario questions that come up again and again. Each one says what it is really checking, how to approach it, and a short set of guidelines to follow.

How should you answer any of these?

Use the same four moves every time, out loud, and the interviewer can follow you:

1. Restate the problem and ask one or two clarifying questions. Who is affected, and what does success look like?
2. Name what you would look at first: data, research, the current experience, constraints.
3. Make a choice and say what you gave up. Every real decision has a cost.
4. Say how you would know it worked, with a measure you could actually check.

1. What do you do when the number of users suddenly multiplies?

What it tests: whether you think about systems and not only screens.

Start with what breaks first at ten times the volume: search, lists, notifications, onboarding, support. Separate the experience that must stay the same for everyone from the parts that can adapt, such as defaults, filters and saved views.

Guidelines

• Name the two or three screens that would suffer most, and say why.
• Treat performance, loading and empty states as design problems.
• Plan how you would notice new kinds of users with different needs.
• Avoid redesigning everything. Scale the parts that strain.

2. People keep dropping out of an important flow. What now?

What it tests: diagnosis before design.

Find where they leave (funnel data), then why (session recordings, short interviews, support tickets). Look for the usual causes: too many steps, unclear wording, surprise costs, a form that rejects good input, a slow screen.

Guidelines

• Define the measure first, for example the share of people who finish the task.
• Combine numbers (where) with conversations (why).
• Change one thing at a time where you can, so you know what worked.
• Avoid jumping to a redesign before you have found the cause.

3. Engagement is high but conversions are falling. What would you investigate?

What it tests: whether you question a metric that looks healthy.

High activity can mean people are interested, or lost. Check whether the busiest screens are the ones people use to get unstuck, whether a recent change moved the call to action, and whether the audience mix has shifted.

Guidelines

• Compare segments (new and returning, device, source) before comparing averages.
• Ask what changed recently in the product, the traffic or the pricing.
• Talk to a few users who were engaged but did not convert.
• Avoid treating engagement as success without asking what it is for.

4. A key feature stops working. How do you design for it?

What it tests: care for people on a bad day.

A good error state says what happened in plain words, tells the person what is safe (their data, their order), and offers a next step: retry, an alternative, or a way to reach a human.

Guidelines

• Write the message for a stressed person: short, specific and blame-free.
• Save progress so nothing is lost, and say so.
• Offer a way to be told when it is fixed.
• Tell a small hiccup apart from an outage, because they need different tones.

5. An enterprise product has overlapping features and confusing navigation. Where do you begin?

What it tests: structure, and the courage to simplify.

Inventory what exists, then group it by what people are trying to do and not by how the company is organised. Card sorting and tree testing give you evidence.

Guidelines

• Start with an audit and a list of real tasks by role.
• Decide what to merge, what to hide behind permissions and what to retire.
• Roll the change out in stages so long-time users are not stranded.
• Avoid a big-bang relaunch with no way back.

6. Stakeholders disagree with your research. How do you respond?

What it tests: influence without ego.

Find out what each person is worried about. Show the evidence in terms they care about, such as cost, risk and revenue, not only user quotes.

Guidelines

• Listen for the concern behind the objection.
• Offer a small test that could settle the question.
• Be ready to change your mind if the result surprises you.
• Avoid turning it into a contest. Defending a decision is not defending your pride.

7. Different teams build inconsistent interface patterns. What do you do?

What it tests: whether you can create leverage for others.

Audit the real product first and count the duplicates. Start with the few components used everywhere, name them, document when to use each, and publish them where teams already work. See the UX glossary for the terms.

Guidelines

• Begin small: the five components that appear most often.
• Plan adoption as carefully as design: contribution rules, versioning, and a way to say no.
• Measure use, not only completeness.
• Avoid building a library nobody asked for.

8. Design a complete food delivery experience. What would you improve?

What it tests: end-to-end product thinking.

Split the journey into discovery, choosing, checkout, waiting, delivery and coming back. For each stage name one real friction: too many restaurants and no way to narrow them, hidden fees at checkout, no honest delivery estimate, no easy way to fix a problem.

Guidelines

• Pick one or two changes with the most impact and explain why.
• For retention, talk about reordering and trust after a bad order, not only discounts.
• Say who you are designing for first: the eater, the courier or the restaurant.
• Avoid listing ten ideas with no priority.

9. Design an analytics dashboard. Which measures and charts would you choose?

What it tests: whether you start from decisions, not from charts.

Ask who uses it and what decision they make with it on Monday morning. Choose a handful of measures that answer those decisions, show change over time and against a target, and make it obvious what needs attention.

Guidelines

• Match the chart to the question: trends as lines, comparisons as bars.
• Limit the first view to what drives a decision.
• Design empty, loading and error states.
• Avoid filling the screen with every number available.

10. You have a crowded roadmap and only time for part of it. How do you prioritise?

What it tests: judgment under constraints.

Show that you can weigh value against effort and risk without hiding behind a formula. Start from the goal the team is trying to reach, list what could move it, and be clear about what you would leave out.

Guidelines

• Tie each option to a goal and a user problem.
• Use a simple framework (impact, effort, confidence) as a conversation tool, not as the answer.
• Say what you would cut, and what it would cost.
• Involve engineering early so estimates are honest.

11. How would you design an AI-assisted feature that people can trust?

What it tests: whether you can design for uncertainty.

AI features can be wrong, slow or surprising. Good answers cover how people understand what the system did, correct it, and stay in control.

Guidelines

• Show what the AI used and how sure it is, in plain words.
• Make mistakes easy to undo and easy to report.
• Keep a manual path for people who prefer it.
• Avoid presenting a guess as a fact.

12. You find an accessibility problem a week before launch. What do you do?

What it tests: your standards, and how you act when they cost something.

Assess how serious the problem is: does it stop someone completing a core task? Then propose options with trade-offs, such as a quick fix now, a staged release, or a delay, and recommend one.

Guidelines

• Check against a clear standard such as WCAG, and name the criterion.
• Bring a fix or a workaround, not only the problem.
• Explain the effect on real people and on the business.
• Avoid making it a one-off. Say how you would catch it earlier next time.

How do you practise?

• Answer aloud, with a timer. Five minutes per question is enough to feel the pressure.
• Practise with a person, or record yourself and listen for rambling.
• Prepare two or three stories from your own work that you can bend to fit a question: one failure, one disagreement, one result you measured.
• Keep a list of questions to ask back. Good designers ask about constraints and success measures.

Related reading

• Browse design jobs and salary insights to see what employers ask for.
• Compare your work with real UX portfolios.
• Ask for advice in the Career Advice topic.

FAQ

What do product design interviews ask besides portfolio questions?

Most include scenario questions about improving an existing product, a case study walk-through, a conversation about working with engineers and stakeholders, and sometimes a short design exercise. The scenario questions test how you reason when the problem is not neatly defined.

How long should my answer to a scenario question be?

Aim for three to five minutes. Restate the problem, say what you would look at, make a choice and explain how you would measure it. The interviewer will ask follow-up questions, so you do not need to cover everything at once.

Do I need to sketch during the answer?

Only if it helps you explain. Many interviewers care more about the reasoning than the drawing. If you do sketch, keep it rough and talk through it.

What if I do not know the product or industry in the question?

Say so, ask a clarifying question and reason from people's goals. Interviewers rarely expect domain expertise. They want to see a sound method and honest assumptions.

How do I show business impact if my past work had no numbers?

Use what you do have: what changed, what feedback you got, how the team used your work. Be honest about what you measured and what you only observed.