UX and UI designer interview questions

How a designer interview loop is structured

The recruiter screen checks scope and level: what you owned, team size, which part of the process you ran yourself, and whether you work in research, interaction, visual craft or all three. The portfolio round is a presentation, usually 45 minutes with questions throughout, on one or two projects. The exercise is either a live prompt at a whiteboard or an unmoderated take-home, sometimes replaced by a critique of an existing product. The cross-functional rounds test collaboration, and they are rarely about design at all.

The US Bureau of Labor Statistics describes digital designers as developing, creating and testing website or interface layout, functions and navigation for usability, with duties that include creating prototypes and mockups and working with other designers to determine layout. That phrase about testing for usability is the part candidates underplay. In most loops there is at least one interviewer whose only question is how you knew your design worked.

Ui ux interview questions vary by company shape. A product team with researchers will press on interaction and systems thinking; a small team without them will press on whether you can run a usable study yourself. Ask the recruiter who is on the panel and what each round is for. Nobody minds the question, and it lets you prepare the right project.

The portfolio review

Choose depth over range. Two projects presented properly beat six summarised, and the strongest choice is usually a messy project with a real constraint rather than the prettiest one. Interviewers want to see thinking under pressure, which polished redesigns rarely show.

Give each case study the same spine: the problem and who had it, how you know that was the problem, the constraints you worked inside, two or three options you considered, what you chose and why you rejected the others, what shipped, and what happened next. The rejected options are the part that marks a senior candidate, because design is the discipline of choosing between imperfect answers. If a project never shipped, say so early and explain what stopped it rather than letting someone discover it in question time.

Be explicit about your own role. Panels ask directly who did the research, who drew the flows, who made the final visual decisions, and vague answers read as borrowed credit. It is fine to say a researcher ran the interviews and you synthesised them, as long as you say it.

Rehearse to time with the screen you will actually use, and prepare for interruption, since the questions come mid-slide rather than at the end. Keep the first two minutes tight: the problem, your role, the outcome. Then let the panel pull on whichever thread interests them, which is also a signal of what the team cares about.

The design exercise and the product critique

A whiteboard prompt is deliberately broad: design a way for commuters to report a broken lift, or improve the booking flow of a clinic. The marks go to process, so narrate it.

Start by restating the problem and asking what you are allowed to assume: who the user is, what they are doing right before this moment, which platform, what the business needs out of it, and what success would look like. Then pick a specific user and a specific scenario out loud, since designing for everybody produces nothing. Map the flow before the screens, name the step where people fail today, and sketch only the two or three screens that carry the decision. Say what you would cut if the engineering estimate came back at twice the budget, and say what you would test first if you had one round of research.

For a take-home, keep the deliverable short and the thinking visible: the problem, your assumptions, the flow, two options, the one you chose, and the open questions. Ask about the time budget and stay inside it. If an exercise is scoped like unpaid production work rather than a sample of your thinking, it is reasonable to ask whether an existing case study could be presented instead.

For a critique prompt, the trap is listing cosmetic complaints. Lead with what the product is trying to achieve and for whom, then name the two problems that most block that goal, with a hypothesis about why the team may have shipped it that way. Generosity about constraints you cannot see reads as experience, not softness.

User interface design questions and craft checks

Interface questions get concrete fast. Expect to be asked how you establish hierarchy on a dense screen, how you handle the states nobody designs (empty, loading, partial data, error, too much data), how you pick type sizes and spacing, when a modal is the wrong answer, and how you decide between a dropdown, radio buttons and a segmented control.

Accessibility is now a standard part of this round, and precision helps. The W3C’s WCAG success criterion on contrast requires that the visual presentation of text and images of text has a contrast ratio of at least 4.5:1, with large-scale text and images of large-scale text at a ratio of at least 3:1. Beyond contrast, be ready to say that every interactive control should be reachable and operable from the keyboard with a visible focus state, that colour alone should never carry meaning, that form fields need persistent visible labels rather than placeholder text, and that touch targets need enough size and spacing to be hit reliably. One concrete accessibility fix you made in a real project is worth more here than any checklist.

Design systems come up in almost every ui ux designer interview. Useful answers cover when you use a component as it is, when you extend it, and when you make the case to change the system itself, plus how you document the decision for the next person. On handoff, describe what engineers actually need: states, behaviour at each breakpoint, error copy, what happens with long strings or missing data, and which decisions are flexible. Saying that you check the build before release, and what you look for, lands well with the engineer on the panel.

Research, testing and measuring success

Ux questions about research are not asking you to be a researcher. They are checking whether you know which method answers which question, and whether you can act on a small amount of evidence.

Keep the distinction clean. Interviews and usability sessions tell you why something happens and what people are trying to do; analytics and surveys tell you how often it happens and to how many. Exploratory questions call for talking to people; questions about whether a specific design works call for watching people use it; questions about which of two versions performs better call for an experiment, if the traffic supports one.

Be ready to describe a usability test you ran: the task you set, how you avoided leading the participant, how you recorded what you saw, and the change you made as a result. Mention the small-sample honesty that experienced designers have, that a handful of sessions surfaces obvious failures reliably and tells you little about preference or magnitude. Say what you would do when there is no budget for research: five customer support tickets, a session recording, a conversation with the sales team or the service desk, all of which are available on a Tuesday afternoon.

On measurement, pick metrics tied to the behaviour you changed: task completion, time to first success, error or correction rate, drop-off at the step you redesigned, repeat use. Then add the caveat interviewers want to hear, that a metric moving does not prove your design caused it, and name what else was happening at the time.

Collaboration and the questions behind the questions

The cross-functional rounds use ordinary behavioural prompts, and designers often answer them too abstractly. Expect: tell me about a time you disagreed with a product manager; a time an engineer said your design was not feasible; a time you received critique you did not accept; a time you shipped something you were not proud of; how you work when requirements change halfway through.

Answer in specifics, with the words that were said and what you did next. Strong answers show that you treat feasibility as a design input rather than an obstacle, and that you can separate a principle worth defending from a preference worth dropping. When you describe a disagreement, say how it ended and what you would do differently, and avoid making the other person the villain. Panels are quietly assessing whether their engineers would enjoy the next sprint with you.

Ui ux interview questions and answers that get rehearsed to death tend to be the weakest part of a strong candidate’s loop, so use a plain structure instead: situation, task, action, result, with most of the time on your own actions. Behavioral interview questions covers the common prompts, and the STAR method page covers the shape.

Finally, prepare three questions of your own. Good ones for design roles: how design work gets prioritised, what happened to the last design decision the team disagreed on, and who owns research. The answers tell you more about the job than the job description did; questions to ask the interviewer has more.