UX interview questions (and how to answer them)

Tell me about a time you disagreed with a product manager or engineer.

They are testing collaboration, not whether you won. Show that you argued from user evidence, sought the strongest version of their view, and committed to the decision even when it went against you. "I was right and they were wrong" is the answer that fails.

Describe a project that failed, or a design that did not work.

Pick a real failure and own your part in it. The interviewer wants evidence you can learn in public. Name what you would do differently and the principle you took away - a candidate with no failures has either not shipped much or is not being honest.

How do you handle critical feedback on your work?

Frame feedback as data about the design, not about you. Give an example where feedback genuinely changed your direction. This pairs well with how you run a design critique - the same non-defensive posture applies whether you are giving or receiving.

Tell me about a time you had to ship with less than you wanted.

Real UX lives inside constraints. Show you can find the smallest thing that still solves the core problem - the spirit of an MVP - and that you tracked what to fix next rather than treating the compromise as final.

How do you advocate for the user when the business pushes back?

The strongest answer reframes user value as business value. Talk in the language of outcomes they care about - a north-star metric, retention, conversion - and show you brought evidence, not just opinion.

Walk me through your design process.

Do not recite a waterfall. Describe a loop - understand, explore, test, refine - and immediately show where you bent it on a real project. If you lean on a model like design thinking or the double diamond, treat it as a map you deviate from, not a script.

How do you decide between two design directions?

Show a decision method, not a gut call: define the user problem, weigh each option against it, and test the assumption cheaply - a first-click test or a five-second test settles more debates than another opinion in the room.

How do you keep interfaces simple as they grow?

Name the forces at play. Reference Hick's law (more choices, slower decisions), cognitive load, and progressive disclosure as your tools for revealing complexity only when needed.

What makes a good interface, in your view?

Answer with principles you can defend: clear affordances and signifiers, quick feedback, error prevention over error messages, and honest constraints. Tie each to something the interviewer can see on their own product.

How do you make sure your work is accessible?

Show it is built in, not bolted on: semantic HTML first, sufficient colour contrast, meaningful alt text, and testing with a keyboard and a screen reader - accessibility built in from the first commit, not audited in at the end.

How do you work with a design system?

Show you value consistency without treating the system as a cage. Talk about atomic design thinking, when to reuse a component versus propose a new pattern, and how you feed improvements back rather than quietly overriding it.

Walk me through a project you are proud of.

Lead with the problem and who had it, not the solution. Then the key decisions, what you ruled out and why, and the measurable result. Rehearse a five-minute and a fifteen-minute version - you will be cut short at least once.

What was the hardest trade-off in this project?

Have one ready. This question separates people who followed a brief from people who own decisions. Name the tension, the options, the evidence, and why you chose as you did - even if you would choose differently now.

How did you know your design worked?

Connect the work to a measurement. Whether it was usability testing, an A/B test, or a shift in a real metric, show you closed the loop instead of shipping and hoping.

What would you change if you did it again?

Never say "nothing". Reflective honesty reads as seniority. Pick one real improvement and the principle behind it - it shows you are still learning from your own work.

What was your specific contribution?

Be precise about "I" versus "we". Interviewers are wary of borrowed team credit. Name exactly what you led, and be generous and clear about what others did.

Critique this screen / app for me.

Do not just list dislikes. Pass it through clear lenses: who is the user and goal, what does Nielsen's heuristics flag, is it accessible, and what would you test first? A structured heuristic evaluation beats scattered opinions every time.

Design a [product] for [user] on a whiteboard.

Spend the first minutes on the problem, not the UI. Clarify the user and the job, sketch the information architecture and flow, then a rough wireframe at low fidelity. State your assumptions aloud and invite the interviewer in.

How would you improve our onboarding / checkout?

Anchor on the goal and the drop-off, not aesthetics. Reduce steps and choices (Hick's law), remove friction, and name what you would measure - conversion and completion - to know it worked.

You have five minutes - where do you start?

Say your structure before you dive in: "I will define the user and goal, find the biggest friction, propose one change, and say how I would test it." Announcing a structure is itself part of what they are scoring.

How do you choose a research method?

Match method to question. Generative and unsure? Talk to people or run diary studies. Structuring navigation? Card sorting and tree testing. Testing a design? Usability testing with a think-aloud protocol.

How do you run a usability test?

Show the essentials: a real task, not a demo; watch behaviour, not opinions; stay quiet and let them struggle. Five users surface most major issues. Then synthesise with something like affinity mapping.

How do you research with no time or budget?

Pragmatism reads as seniority. Guerrilla tests, five quick sessions, a heuristic evaluation, or existing analytics all beat no research. Be clear-eyed about the limits of synthetic users and personas as a stand-in for real people.

How do you turn research into design decisions?

Close the gap between insight and action. Cluster findings, map them to the user journey or an empathy map, and turn the top themes into design changes you can point back to the evidence for.

What is a product you love, and how would you improve it?

Pick something you genuinely use, name who it serves and the job it does (its job to be done), then propose one improvement tied to a user need and a metric - not a coat of paint.

How would you measure the success of this feature?

Show you think past launch. Pick a primary metric that reflects real value (often a north-star metric), a guardrail so you do not win one number by wrecking another, and how you would read conversion against intent.

How would you design for [a very different user]?

Resist designing for yourself - the curse of knowledge is the trap here. Start from that user's context and constraints, and say what you would need to learn first rather than assuming.

Where does UX end and product begin, for you?

Show you see the whole system. Reference the UX honeycomb or the 5 Es of usability to frame UX as value plus usability plus desirability, and talk about partnering with product rather than guarding a boundary.