UX designer interview questions and answers (UK, 2026)
The portfolio walkthrough, critique and evidence questions UK UX interviews really ask, and how to present work that survives senior questioning.
What interviewers are really assessing
The panel has seen hundreds of beautiful portfolios built on invented process, so the walkthrough is an interrogation of decisions: why this flow, what did you know about users when you chose it, what else did you try, what happened after launch, and where the honest answer is "we guessed under deadline", they want that honesty rather than retrofitted research theatre. Critique rounds test how you take and give feedback, because design crit is the daily working ritual and defensiveness is disqualifying. Cross-functional interviewers (a product manager, an engineer) probe how you handle being overruled, scope pressure and technical constraints. Accessibility has moved from nice-to-know to screened-for, especially in public sector work where WCAG compliance is legally required and the GOV.UK Design System sets expectations. Whiteboard exercises mark structure over polish: framing the problem, asking about users and constraints before drawing, and reasoning aloud.
UX Designer interview questions and model answers
For each question: why it is asked, and the structure of a strong answer. Adapt the worked examples to your own experience; interviewers follow up, so never borrow a story.
1. Walk me through one project: the problem, your process, and what shipped. I will interrupt with questions.
Why they ask it: The interrupted walkthrough is the core assessment: it distinguishes designers who made decisions from designers who made deliverables.
Choose the case with the most decisions, not the prettiest screens: state the problem and its business stakes, what you knew about users and how (be precise: five usability sessions, support ticket analysis, analytics funnels, and equally precise about what you did not know), the key design decisions with the alternatives you rejected and why, the constraints that shaped it (technical, regulatory, deadline), and the outcome with numbers: task completion, conversion, support contacts, adoption. Prepare for the interruptions: any claim (users struggled with X) will get "how do you know?". The differentiator is trade-off honesty: "we shipped the simpler flow because the better one needed backend work we could not get; here is what it cost us and how we knew".
2. Tell me about a time you had little or no research and had to design anyway. What did you do?
Why they ask it: Deadline reality means every designer works under-evidenced sometimes, and panels trust designers who manage that honestly over ones who claim full process always.
Show rigour under constraint: mining what exists (analytics, support tickets, sales call notes, past research on adjacent problems, competitor teardowns), stating assumptions explicitly and designing them to be testable, shipping instrumented so the launch itself becomes the research, and the cheapest possible validation slotted in: five hallway sessions, an unmoderated test overnight, a prototype in front of two customer-facing colleagues. A worked example: designing a checkout change on analytics and heuristics alone, flagging the riskiest assumption (users would understand the new delivery picker), catching a failure in three quick sessions and fixing it pre-launch. The failing answers: pretending you always have research, or treating its absence as licence to just make it look nice.
3. Describe a design decision you fought for and lost. What happened?
Why they ask it: Being overruled is routine in product teams, and the panel is testing both your advocacy and your behaviour after the decision.
Pick a real loss: a flow simplified against your evidence, a dark-pattern-adjacent request you resisted, a feature shipped before the usability issues were fixed. Show the advocacy done properly: your case made with evidence and user impact rather than taste, alternatives offered, the decision-maker's constraints understood (revenue pressure, a contract deadline). Then the professional after: you committed to the shipped version, instrumented it, and brought data back rather than sulking or sandbagging, and sometimes the follow-up: the metrics proved your concern and the fix got prioritised, or they did not and you updated your judgement. Panels are screening out both pushovers and martyrs; the designer they want loses arguments gracefully and wins the rematch with evidence.
4. How do you work with engineers and product managers day to day, and where does design friction actually show up?
Why they ask it: Most design failure is collaboration failure, and cross-functional interviewers are checking you will make their teams better, not slower.
Show the working practices: engineers involved before the design is "done" (feasibility conversations that reshape solutions early, not handoff surprises), specs that answer the questions engineers actually have (states, edge cases, empty and error states, not just the happy path), and product trade-off conversations where you bring options with costs rather than a single precious solution. Name real friction honestly: the design degraded in build because you specified too little, the PM who treated design as decoration, the sprint pressure that ships the 80 percent version, and how you handled each. The detail that lands: examples of changing your design because an engineer's cheaper alternative was almost as good, because that judgement is what teams want in the room.
5. How do you measure whether your design worked?
Why they ask it: Designers who cannot connect work to outcomes stay junior, and panels probe whether your metrics literacy is real.
Show the practice: success metrics defined before shipping, not retrofitted (what should move: task completion, time to complete, conversion at the step, error rate, support contacts on the topic, retention for engagement-level changes), instrumented with analytics plus the qualitative layer that explains the numbers: session recordings, follow-up usability sessions, feedback widgets. Give a worked loop: a redesigned onboarding measured on activation rate, which rose, but session recordings showed a new confusion point that the next iteration fixed. Include the honest half: a design that did not move the metric and what you did about it. Guardrails matter too: the conversion win that spiked support tickets is not a win, and saying so shows maturity.
6. What does accessibility mean in your actual workflow, not in principle?
Why they ask it: WCAG compliance is legally required in UK public sector and increasingly screened everywhere, and panels can tell workflow from slideware instantly.
Ground it in habits: designing to WCAG AA as default (contrast checked at the design stage with real tools, touch targets sized, focus order and keyboard paths designed rather than left to chance, error messages that say what to do), annotating accessibility intent in handoff (labels, headings hierarchy, what the screen reader should announce), and testing beyond the checker: keyboard-only runs, a screen reader pass on critical flows. If you have public sector experience, name the regulations and the GOV.UK Design System patterns; if not, show the transferable discipline. One concrete story, such as catching a colour-only status indicator and redesigning it with icons and text, proves the habit. The failing answer treats accessibility as an audit that happens to other people.
7. Critique this screen for me: our product's, or one you know well. Talk me through what you see.
Why they ask it: Live critique reveals your design judgement raw, without portfolio rehearsal, and how you deliver criticism of someone's work to their face.
Show structured looking, not hot takes: orient first (who is this for, what is the user trying to do here, what is the screen's one job), then work through hierarchy (does the visual weight match task importance), clarity (labels, affordances, what is tappable), flow (where did the user come from, what is next), and states (what happens on error, empty, loading). Deliver it with critique manners: observations and questions over verdicts ("I notice the primary action competes with three others; what was the thinking?"), strengths named genuinely, and severity distinguished: what would confuse everyone versus what is polish. If it is their product, having used it beforehand is the preparation that separates candidates; say what you found as a real user.
8. Why this company and product, and where is your craft heading: specialist IC, lead, research-leaning, systems?
Why they ask it: Design teams are small and fit matters; panels want your trajectory to match what the role can actually feed.
Show product-specific motivation: you have used their product and have a genuine observation (a flow you admired, a friction you hit, a design challenge their domain creates: complexity, trust, regulation), and connect their context to what you want next: a design system to mature, research muscles to build, a domain with meaty problems. On trajectory, be honest: deepening as a senior IC, moving toward leading, specialising in research or systems, and check the role offers it: crit culture, research access, mentorship. Asking how design decisions actually get made there, and what the last design-led win was, signals you are choosing a design environment, not just a job title, which is exactly what strong teams want chosen for.
Questions to ask them
Asking nothing reads as low interest. These three work because they show you understand the role’s reality, and their answers tell you whether you want the job:
- How do design decisions actually get made here: who has final say when design, product and engineering disagree?
- What research access do designers have: can I talk to users directly, and how often does that happen in practice?
- What is the crit culture like: how does design feedback work day to day, and how are designers mentored?
Practise out loud, not in your head
Reading model answers feels like preparation, but interviews are spoken: the first time you say an answer aloud should not be in the room. Rehearse each story out loud until it flows without sounding scripted. If you want a realistic run-through, Vouch’s AI coach Maya runs voice mock interviews built from a real job advert and your own CV, and gives feedback per question, which is the closest thing to the actual experience you can do from your sofa.
And since a strong interview starts with getting invited: the free cover letter generator writes a UK-format letter from your real experience, and the UK personal statement guide covers the 50-80 words at the top of your CV that decide whether it gets read.
Frequently asked questions
How should I prepare for a UX designer interview?
Prepare two case studies you can defend under interruption: decisions, evidence, trade-offs and outcomes with numbers, plus honest answers for the gaps in your process. Use the company's product beforehand and form one specific observation. Rehearse a whiteboard structure (frame the problem, ask about users and constraints, explore options aloud, converge with reasons) and refresh WCAG basics, because accessibility questions are now standard.
What format do UK UX designer interviews take?
Typically three or four stages over two to four weeks: a recruiter or hiring manager screen, a portfolio walkthrough with designers (the core assessment), a cross-functional round with product and engineering, and often a design exercise: a live whiteboard challenge or a time-boxed take-home critiqued in person. Public sector processes add formal criteria scoring and accessibility emphasis; senior roles add leadership and stakeholder scenarios.
How do I answer the salary question in a UX designer interview?
Benchmark by market and level honestly: London and fintech pay above regional and agency norms, and the title inflation across the industry means comparing scope (do you own research, systems, a product area) rather than titles. Give a researched range tied to your evidence: shipped outcomes with metrics, specialist skills (research, design systems, accessibility), and domain experience. Ask about progression structure and how design levels are defined, because a clear levelling framework predicts your salary trajectory better than the starting number.