UX designer interview questions, with worked answers

How to use these questions

Pick two projects from your portfolio that you know inside out, and practise telling each in five minutes and in twenty. Most questions below can be answered with one of them. Say what you did, what the team did, and what you would do differently now.

What a UX designer is expected to know

• Research: interviews, usability tests, surveys and analytics, and when each fits.
• Structure and interaction: information architecture, user flows, wireframes and prototypes.
• Craft and systems: layout, type and components, design systems, and the tool most teams share, FigmaFlows, components, variants and prototypes in the tool most teams share with developers..
• Accessibility: WCAG, the web's accessibility guidelines, and designing for keyboards, screen readers and low vision.
• Team and results: working with developers and product managers in agileDesign in short cycles alongside development, a step or two ahead of the build. teams, and measuring whether a design worked with product dataRead product data to find where people struggle and to check whether a change helped..

Your portfolio and your process

Walk me through a case study from your portfolio.

What they check: how you think, from the problem to the result, and what was yours.

Short answer: "I tell it in five parts: the problem and who had it, what we learned from research, the options we explored, what we chose and why, and what happened after release. I say my role in the team, and I point out the moment the research changed our plan."

The full answer, in five parts:

1. The problem. One or two sentences with a fact: "half of new customers abandoned the sign-up on the identity step". Name the users and the business goal.
2. What you learned. The research you did, such as interviews, a usability test or analytics, and the two or three findings that mattered.
3. The options. Show a few directions you explored and why you dropped some. This is where interviewers see judgement.
4. The decision. What you designed, the trade-offs, and what you agreed with developers and the product manager to ship first.
5. The result. A number if you have one, such as completion rate or support tickets, and what you would change now.

A weak answer: showing final screens one after another and describing the colours. The process is the answer.

Follow-up: "What would you have done with twice the time?" Name the research you skipped and the risk it left, such as testing with users of assistive technology.

How do you choose a research method for a question?

What they check: that you match the research method to what you need to learn.

Short answer: "I start from the question. If we do not yet know the problem, I use generative research such as interviews or field visits. If we have a design to check, I use evaluative research such as usability tests. If I need to know how many people do something, I use analytics or a survey. Small qualitative studies tell me why; numbers tell me how much."

The full answer: Two axes help: what people say against what they do, and why against how many. Interviews capture what people say and why; usability tests show what they do; analytics show what many people do but not why; surveys count opinions. Combine them: analytics find the step where people drop off, a test shows why. Budget and time matter too: five quick tests now often beat a perfect study next quarter.

A weak answer: "I always do a survey." Follow-up: "You have one week and no budget." Run a few remote tests with people from the customer list or colleagues outside the project, and say clearly what that sample cannot tell you.

How do you run a user interview that gives you honest answers?

What they check: interview skill: open questions, no leading, and listening.

Short answer: "I ask about what people did recently, not what they would do: "tell me about the last time you booked a trip" rather than "would you use this feature?". I keep questions open, stay quiet after answers so they say more, and never pitch the product. Someone else takes notes, so I can listen."

The full answer: Prepare a short guide with topics, not a script. Start easy, then go into the moments that matter, and ask "why" and "what happened next". Watch for the gap between what people say and what they did. People are polite, so praise means little; workarounds and complaints mean a lot. After five to eight interviews, patterns usually start to repeat.

A weak answer: "I show them the design and ask if they like it." Follow-up: "A participant asks for a specific feature." Ask what problem it would solve for them; the problem is the finding, not the feature.

How do you turn research findings into design decisions?

What they check: synthesis: moving from many notes to a few clear insights the team acts on.

Short answer: "I group the notes from all sessions by theme, often on a shared board, which is called affinity mapping. The themes become a few insights, each with evidence and how often it came up. I share them with the team in a short session and agree which to act on, linked to the product goals."

The full answer: Involve developers and the product manager in the sessions or the synthesis; people believe what they saw. Write each insight as a problem, not a solution: "people do not trust the price until they see the fees" leaves room for ideas. Rank by how many users it affects and how badly, and keep the raw notes so anyone can check. Turn the top insights into design goals you can test later.

A weak answer: "I write a long report." Few people read it. Follow-up: "The findings contradict what the CEO believes." Show the evidence, clips if you have them, and propose a small test that settles it.

Testing, structure and accessibility

How do you plan and run a usability test?

What they check: a usability test that gives clear, usable results.

Short answer: "I decide what we need to learn, write realistic tasks around it, recruit five or so people who match our users, and ask them to think aloud while they try the tasks on a prototype or the live product. I note where they hesitate or fail, measure task success, and share the top problems with the team the same week."

The full answer, in five steps:

1. Goal. One or two questions, such as "can new customers change their delivery date without help?".
2. Tasks. Realistic scenarios in the user's words, without the words on the buttons, so you do not give the answer away.
3. People. About five per user group find most of the big problems; test again after fixing rather than testing more people once.
4. Session. Ask them to think aloud, stay neutral, and do not help unless they are stuck for good. Record with permission.
5. Results. Task success, time and errors per task, and the problems ranked by how serious and how frequent they were, with a clip for each.

A weak answer: "I ask users whether they find it easy." Watch what they do instead. Follow-up: "Only two of five people failed a task. Is that a problem?" Yes, if the task is important; small tests find problems, they do not measure exact rates.

How would you design the information architecture of a large website or app?

What they check: structure that matches how users think, tested rather than guessed.

Short answer: "Information architecture is how content is organised and labelled so people can find it. I start with an inventory of what exists, then run a card sort, where users group topics in a way that makes sense to them. I draft a structure, test it with a tree test, where people find items in a text-only menu, and adjust labels until most find things first time."

The full answer: Open card sorts, where users name their own groups, show their mental model; closed sorts check a draft structure. Tree tests measure findability without the visual design in the way. Labels matter as much as structure: use the words users use, found in search logs and support tickets. Plan for growth, so new content has an obvious place, and add search for people who prefer it.

A weak answer: "I copy the company's departments into the menu." Users do not think in departments. Follow-up: "Two teams both want their section at the top." Show the tree test results; the users' success rate settles it.

How do you make a design accessible?

What they check: accessibility built in from the start, at the level of WCAG AA.

Short answer: "I design to WCAG, the Web Content Accessibility Guidelines, at level AA: enough colour contrast, text that can be enlarged, every action possible with a keyboard, a visible focus, labels for screen readers, errors that say how to fix them, and nothing that relies on colour alone. I note these in the designs for developers and test with assistive technology."

The full answer: Accessibility helps far more people than those with a permanent disability: someone with a broken arm, bright sunlight on a phone, an older user. Check contrast while choosing colours, not afterwards. Design focus states, error states and the reading order, and write the text for icons and images. Test with a keyboard and a screen reader yourself, and include disabled people in research. In the EU, the European Accessibility Act (EU) makes many consumer services a legal duty, not a nice-to-have.

A weak answer: "Accessibility is checked by the developers at the end." Follow-up: "The brand colour fails the contrast check." Keep it for large elements and use a darker shade for text and buttons, agreed with the brand team.

Design systems, prototypes and working with the team

What makes a design system work?

What they check: that you see a design system as a shared product, not a sticker sheet.

Short answer: "A design system is a shared set of components, rules and guidance that designers and developers both use, so the product looks and works the same everywhere. It works when the components in FigmaFlows, components, variants and prototypes in the tool most teams share with developers. match the ones in code, when there are clear rules on when to use what, and when someone owns it and teams can propose changes."

The full answer: Start from what the product already uses most, such as buttons, form fields and messages, not from a complete library. Design tokens, named values for colours, spacing and type, keep design and code in step. Each component documents its states, its accessibility and do's and don'ts. Treat it as a product: a backlog, releases, and a way for teams to contribute. Measure adoption, not the number of components.

A weak answer: "It is our Figma file of components." Without code and owners it drifts. Follow-up: "A team needs a component the system does not have." Let them build it within the rules, then review whether it belongs in the system for everyone.

When do you prototype in low fidelity, and when in high?

What they check: that prototyping effort follows the question you need answered.

Short answer: "Low fidelity, sketches or simple wireframes, when the question is about the idea or the flow, because people comment on the concept and not the colours, and changes cost minutes. High fidelity, a clickable prototype that looks real, when I need to test details such as wording, layout or a complex interaction, or to show the final direction."

The full answer: Match the prototype to the risk. Early, explore several directions quickly on paper or in rough frames. Later, test the chosen one at the fidelity of the decision: a form's error messages need real text; a navigation idea does not. Some interactions, such as drag and drop, only feel right in code; then pair with a developer on a coded prototype.

A weak answer: "I always make pixel-perfect prototypes." It is slow and invites the wrong feedback. Follow-up: "A stakeholder treats the wireframe as final." Say clearly at the start what the prototype is for and what it is not.

How do you work with developers from design to release?

What they check: collaboration that gets the design built well, not thrown over a wall.

Short answer: "I bring developers in early, so they can flag what is hard before the design is final. The hand-off covers every state, such as empty, loading, error and very long text, not only the happy path. I use the shared components, answer questions quickly during the build, and review the result in the browser before release."

The full answer: Most friction comes from surprises: a design that needs data the system does not have, or a component that does not exist. Short check-ins during design avoid them. Knowing how screens are built, through HTML and CSSKnow how screens are built, so your designs fit the web and you can talk with developers in their terms. or the components of ReactA common framework for building interfaces; knowing its components helps you design ones developers can reuse., helps you design things that reuse what exists. When the built version differs, decide together whether it matters to users before asking for changes.

A weak answer: "I send the final file and they build it." Follow-up: "A developer says your interaction will take two weeks." Ask what would take two days, and check whether that version still solves the user's problem.

A product manager wants a feature you think will not help users. What do you do?

What they check: working with product managers through evidence, not opinions.

Short answer: "I first ask what problem the feature should solve and how we will know it worked. Often we agree on the goal and only disagree on the solution. Then I bring what we know about users and suggest the smallest test that would settle it, such as a prototype test or a small release to some users."

The full answer: The product manager owns the what and why of the product; the designer owns how it works for users; both answer for the result. Disagreement is healthy if it ends in a test rather than a contest of opinions. Bring the other people affectedBring product, engineering and business owners to a decision based on what users need. in early, such as support or sales. If the decision goes against you, commit to it and measure it honestly.

A weak answer: "I refuse to design it." Follow-up: "There is no time to test." Agree on the measure before release and a date to review it, so the result decides what stays.

How do you measure whether a design worked?

What they check: that you tie design to metrics, before and after release.

Short answer: "Before the release I agree the measures with the team: a behaviour metric, such as task success or completion rate, a business metric, such as conversion or support tickets, and sometimes a satisfaction score. After release I compare with the baseline, look at where people still drop off, and test again."

The full answer: Usability metrics come from tests: task success, time on task and errors. Product metrics come from analytics, such as funnels in Google AnalyticsFunnels, events and drop-off in the analytics tool many websites use.. Attitude metrics come from surveys, such as the System Usability Scale, a ten-question survey with a standard score. An A/B test, which shows two versions to different users at the same time, separates the design's effect from the season, if traffic is high enough and the statisticsEnough to know when a difference in a test is real and when it is noise. are read with care.

A weak answer: "Users told us they liked it." Follow-up: "Conversion rose, but complaints rose too." Look at who complains and why; a design can push people through a step they later regret.

Senior, lead, principal, design manager and head of design

These questions come up for senior, lead and principal UX designer, design manager and head of design roles.

As a lead or principal designer, how do you raise design quality across teams?

What they check: influence on work you do not do yourself.

Short answer: "I make good work easy and visible: a design system people want to use, regular critiques where designers show work in progress, shared research everyone can find, and a few principles we agreed on. I review the riskiest designs myself and coach designers on the rest."

The full answer: A lead designer guides a team's design work day to day; a principal designer solves the hardest design problems and sets the standard without managing people. Both work through others. Critique works when it is about the goal, not taste: "does this help a first-time user find the price?" Pair with product and engineering leads, so design quality is part of how the product is planned, not a check at the end.

A weak answer: "I redesign their screens when they are not good enough." Follow-up: "A team keeps shipping without design review." Find out why, often time, and offer a lighter review that fits their pace.

As a design manager or head of design, how do you build and run a design team?

What they check: at the top of the ladder, hiring, growth, process and the place of design in the company.

Short answer: "I start from what the company needs from design, then hire for the gaps, such as research or a design system. I give each designer a clear area and a career path, run regular one-to-ones and critiques, and set up the operations that save time, such as research recruiting and shared tools. With leadership, I show design's results in their terms."

The full answer: A design manager leads designers: hiring, feedback, growth and workload. A head of design also shapes how design works across the company: the team structure, the budget, the design system and research practice, and a seat where product decisions are made. Write down what each level means, so promotions are fair. Protect time for research and craft against the pressure to only ship screens.

A weak answer: "I keep designing, and manage on the side." Follow-up: "Leadership asks what design adds." Show two or three results with numbers, such as a redesign that cut support calls, and the cost of the problems research prevented.

Your CV and portfolio for these questions

Interviewers ask about what your portfolio and CV claim, so write lines that lead into the answers above, and make sure each has a case study behind it:

A score against a real UX designer job tells you which of these the employer asks for, so you know which case studies to put first in the portfolio.