UX Designer Interview Questions
(With Answer Frameworks)

Answer framework

Open with the problem in one sentence — who was affected and what was broken. Then describe what research you did and what you learned from it. Walk through your process: how you moved from insight to concept to iteration. Show the solution clearly (have visuals ready). Then close with the outcome — a metric, a shipped product, a user quote. Interviewers who have seen hundreds of portfolios notice immediately when candidates skip the outcome. It signals you do not know whether your work had impact. Always have a number, even an approximate one.

Answer framework

Pick a decision that had trade-offs — not one that was obviously correct. Describe the options you considered, the criteria you used to decide, and the reasoning that tipped it one way. If it went well, say why. If you would revisit it now, say what you know today that you did not know then. The interviewer is not asking which screen looks best — they are asking whether you can articulate a design rationale clearly enough that others can evaluate it and build on it.

Answer framework

This question is a test of how you handle conflict without either caving immediately or digging in irrationally. A strong answer has three beats: you listened and genuinely understood the concern (not just waited for them to stop talking), you either updated your design because they were right, or you advocated for the original direction with additional evidence. The critical part is showing you can tell the difference. Conclude with how the collaboration went and what the outcome was. Interviewers are filtering out designers who cannot work cross-functionally and designers who get steamrolled.

Answer framework

Every project has something you would change. Interviewers ask this to see whether you have a growth mindset and whether you can be honest without being defensive. Pick one real thing — not something so minor it reads as false modesty. Good answers: 'I would have done user testing earlier before we went into high-fidelity' or 'I did not include the engineering lead in the early ideation and we had to redo the interaction model.' Showing you reflect on your work builds more trust than presenting every project as a flawless success.

Answer framework

This constraint is the normal condition, not the exception — so interviewers want to see that you have a real answer, not that you would simply do less. Guerrilla research options: five informal user interviews take four hours total and surface most major usability issues. Hallway testing — asking colleagues who are not familiar with the product to walk through a flow — costs nothing. Existing analytics tell you where users drop off. Competitor reviews show you what patterns the market has already validated. The goal is replacing 'no research' with 'fast, imperfect research' — even one hour of observation beats zero.

Answer framework

A design is done when four things are true: the acceptance criteria for the feature are met, accessibility requirements are verified (WCAG 2.1 AA minimum), edge cases and error states are designed, and the developer handoff is complete — annotated, with specs, assets exported. 'Done' is not 'looks good on my screen in the happy path.' Experienced designers know that half of a design's complexity lives in the edge cases: empty states, error messages, loading states, and what happens when a user does something unexpected. If those are not designed, the design is not done.

Answer framework

The textbook answer is Discover (understand the problem and users), Define (synthesize insights into a clear problem statement), Ideate (generate options, not just one solution), Prototype (build something testable, as low-fidelity as possible for the questions you need to answer), Test (validate with real users or proxies), and Iterate (refine based on what you learned). The nuanced answer — which is what separates junior from senior designers — is that you adapt this process based on time and risk. A low-stakes copy change does not need five rounds of testing. A new onboarding flow for a consumer app does. Know which steps you can compress and why.

Answer framework

Use a simple scoring framework so the decision is transparent and revisable: Impact (how much does solving this improve the user's experience?), Frequency (how many users hit this problem, and how often?), Alignment (does solving this move a metric the business cares about?). Problems that score high on all three go first. Problems that score high on impact but low on frequency may matter deeply to specific users — know whether those users are strategically important. The goal is to replace gut-feel prioritization with something you can explain to a PM and defend in a roadmap meeting.

Answer framework

UX (user experience) is about the overall flow, logic, and feel of a product — does the product help users achieve their goals efficiently and without frustration? UI (user interface) is about the visual and interactive layer — the layout, typography, color, buttons, and components. UX is strategy; UI is execution. A product can have beautiful UI and terrible UX (gorgeous screens that lead users nowhere) or excellent UX and rough UI (flows that make complete sense but look unpolished). They are intertwined — great designers care about both — but they have different success metrics: UX is measured in task completion and satisfaction; UI is measured in visual consistency and design system adherence.

Answer framework

WCAG 2.1 Level AA is the baseline for professional design work and is legally required in many contexts. The rules that come up most often in practice: color contrast ratio of at least 4.5:1 for normal text, keyboard navigation for all interactive elements, meaningful alt text on all informational images, visible focus states so keyboard users know where they are, and never conveying information through color alone (always pair color with a label, icon, or pattern). In Figma, use the A11y plugins to check contrast during design — not just before handoff. Accessibility is cheaper to fix in design than in code.

Answer framework

Recruit five to eight users who represent the actual target audience — not colleagues who already understand the product. Write task scenarios that describe a real goal without revealing how to accomplish it ('You just signed up and want to invite a teammate — go ahead'). During the session, observe without guiding: if a user gets stuck, resist the urge to help. Your discomfort watching someone struggle is the data. Record sessions if possible. After all sessions, synthesize: look for patterns that appeared across multiple users, not one-off moments. Three users struggling with the same flow is a finding; one user making a unique error is probably not. Prioritize findings by severity and frequency before presenting.

Answer framework

Your answer: I bring three things most junior designers with traditional backgrounds do not have. First, fresh perspective — I am not anchored to how things have always been done in UX, which makes me more willing to question assumptions. Second, domain expertise — my background in [previous field] means I understand [specific user group or problem space] at a depth that most designers have to learn from scratch. Third, evidence of initiative — I built this portfolio by [specific actions: taking a bootcamp, doing volunteer projects, redesigning existing apps]. That combination is genuinely different from someone who completed a design degree and followed the standard path. Name your specific advantage — vague claims about being a 'fast learner' do not land.

Answer framework

Counter this by showing the collaborative elements that existed even in self-initiated work: Did you get feedback from potential users? Did you iterate based on that feedback? Did you work with a developer to ship it? If you did any bootcamp group projects, those count — talk about how you navigated differing opinions on direction, how you handled feedback on your work, and how the project changed from what you originally designed. If you have volunteer design work for a nonprofit or open-source project, lead with that. The honest version of this answer is also fine: 'I have not worked in a professional design team yet, but here is how I have built the habits that make that work well.'