UI/UX Designer interview questions
Design interviews center on your portfolio, your process, and a whiteboard/app-critique exercise. Expect to walk through one case study end-to-end.
🎤 Practice these out loud with AceCoach →The questions
What ui/ux designers are tested on
What each round is really testing
A ui/ux designer loop is usually built from 5 kinds of question: Portfolio, Critique, Scrappy, Behavioral, Systems. They are scored separately, which matters more than it sounds — being strong on the technical rounds does not offset a vague behavioural one, because a different interviewer writes that feedback against different criteria and never sees your other scores.
The framework under each question above is not a script to recite. It is the shape of a complete answer — the parts an interviewer is listening for and ticking off. Two candidates can give the same facts and score differently because one of them signposted the structure ("there were three constraints; let me take them in order") and the other produced the same content as an unstructured paragraph. Say the structure out loud; it is doing work.
Turning your own experience into answers
The most common preparation mistake is collecting questions and never building material. Your answers should come from your own work, and your resume is the index of it. Take a line like this one from the ui/ux designer resume example:
Led a 4-month checkout redesign; conversion 5.8% → 7.2%, support tickets -22%, and mobile conversion -8% gap eliminated
A resume bullet is the result with everything else compressed out. An interview answer is the same story decompressed: what the situation was and why it mattered, what you specifically owned, what you tried that did not work, and only then the number. Expect the follow-up to go straight at the part the bullet omits — how you measured it, what you would do differently, who disagreed with you. Prepare the decompressed version of four or five bullets and you have covered most behavioural rounds.
A week of preparation that works
Days one and two: write the decompressed version of five pieces of your own work, each ending in something measured. Day three: rehearse them out loud — this is the step almost everyone skips, and it is where you discover that an answer clear in your head takes ninety seconds and three restarts to say. Days four and five: work the technical questions above, talking through your reasoning rather than solving silently. Day six: prepare your own questions, which are assessed whether or not anyone tells you so. Day seven: rest, and re-read your own notes rather than adding new material.
If you only have an evening, do the spoken rehearsal. It has the highest return per minute of anything on this list, and it is the part that cannot be improvised on the day. AceCoach will ask these questions aloud and score the structure of what you say back, which is the closest thing to the real conditions you can get on your own.
Before the interview
Check the company's format as well as the role's questions — the same ui/ux designer questions are asked very differently at a big-tech loop, an IT services process and a startup. See Big Tech, IT services & consulting or startups & finance. And make sure the resume that got you the interview can survive the questions it invites: everything on it is fair game, and the numbers attract the most scrutiny.
Earlier than the interview? How to become a ui/ux designer covers the routes into this role, what to learn in what order, and what it pays measured from live postings.
Frameworks are guidance, not scripts — the point is to make the answers your own. All roles →
Portfolio and case study structure
Interview panels expect a case study walkthrough that shows your process, not just your output. When you're asked to walk through a project, the hiring manager is listening for evidence that you understand the user, made reasoned decisions, and validated your work. The strongest structure is: problem (what was broken), research (how you learned), exploration (2-3 concepts you tried), the decision (why you picked one), and outcome (metrics or qualitative feedback). This structure shows thinking. A 30-minute case study breakdown should spend 5 minutes on problem, 5 on research, 8 on exploration and decision, and 12 on outcome and reflection. Most candidates reverse it: 25 minutes on "here's what I made" and 5 minutes on why.
Metrics matter even if you can't quantify them perfectly. If you redesigned an onboarding flow, don't just say "users loved it". If you have data, quote it: "completion rate improved from 42% to 67%" or "support tickets about signup dropped 30%". If you don't have hard metrics, quote qualitative research: "users said the new flow reduced confusion around payment; we ran 5 user tests and all completed the flow first try". This shows you measure value, not just aesthetics. Hiring managers care whether your design solved the problem or just looked nice.
Constraints and tradeoffs reveal maturity. If you can't articulate why you made certain choices (font size, color, interaction pattern), you're describing output without reasoning. Better: "we wanted to emphasise urgency in the warning but not overwhelm the form, so we used colour and size differently than typical alerts". Even better if you show the tradeoff: "larger type would have improved clarity but would have broken the grid; we solved it with proximity and whitespace instead". This shows you're balancing multiple needs, not just following best practices.
Collaboration and conflict resolution in design
Design doesn't happen in isolation; it happens with engineers, product managers, and stakeholders. Hiring managers listen for whether you can advocate for users while staying collaborative. The worst answer to "tell me about conflict" is "I was right, they were wrong". A better answer: "the PM wanted to add three new fields to the form. The engineer was concerned about complexity. I ran a quick user test with the current form and tested adding one field at a time. Two fields caused form abandonment to spike; we compromised on one field plus progressive disclosure of the third. Everyone won." This shows: you used data, you understood the constraint (engineer complexity), you proposed a solution both sides could live with.
Remote collaboration is now expected and interviewers check for it. If you've designed across time zones or in fully remote teams, name specifics: how you communicated designs (Figma live session, recorded walkthroughs, async feedback), how you handled real-time feedback, how you unblocked slow feedback loops. Async design reviews are hard because you lose immediate clarification. If you've solved for that (clear documentation, recorded walkthroughs, specific questions for feedback), that's a signal. Designers who only worked in-person in 2024 are behind.
Feedback from non-designers is important to acknowledge. Product managers, engineers, and support teams have insights designers miss. Hiring managers are listening for whether you value that input or dismiss it as non-design feedback. "The support team said users were confused by this term; I updated the copy and ran it by the team again to check" shows you're humble and collaborative. "We ignored feedback from eng because it wasn't a design problem" signals you might be difficult to work with.
Design systems and UX metrics
Design systems work has become critical in product design. If you've contributed to a design system (components, tokens, documentation), your value is multiplied because others can reuse your work. But contributions need evidence. "Worked on design system" is vague. "Built 15 button variants and a spacing system; 20 designers adopted it; it reduced design time per screen by 20%" shows impact. Adoption is the metric that matters: is it actually used, or did you build something and nobody cares?
Consistency versus one-off needs is a constant tension. Hiring managers want to know you can balance them. "We have a design system, but sometimes we need to deviate for marketing or a special feature. How do you decide?" The right answer shows judgment: "default to the system because consistency is valuable, but if deviating improves user value more than consistency costs us, justify it and document it back to the system". This shows you think systematically about tradeoffs.
Measurement of design impact varies by context. If you worked on features with clear metrics (conversion, engagement, retention), quote them. If you worked on internal tools or design systems, metrics are harder but still possible: time saved, adoption rate, reduction in redesigns. If you worked on exploring a new direction (research, concepts), qualitative research is fair: "we ran 8 interviews to explore whether users wanted this feature; 6 of 8 were excited". Different contexts have different measurements. Know which you did and how you measured it.
Frequently asked questions
Should my portfolio include work that isn't shipping or is NDA'd?
Unreleased work is fine. Explain: "this feature shipped in beta in January" or "this shipped internally". If it's NDA'd, you can include it if the company approved, but mention that upfront: "I can show this but I'm under NDA so some details are disguised". Most interviewers understand NDAs. Don't lie or pretend unreleased work is shipped.
How many case studies should my portfolio have?
Three to five strong case studies beat ten shallow ones. Each should be 15-20 minutes to walk through in an interview. Quality matters more than quantity. One case study showing your thinking in depth is more impressive than five where you gloss over the process.
Can I use work from my bootcamp or school projects?
Yes, if the work is substantial and you can speak credibly about it. "Redesigned checkout for an e-commerce project" is fair game even if it was a school project, as long as you did the work. Be honest about context: "for my design bootcamp capstone". Frame it around the skills demonstrated, not the scale or company.
What if my best work is at a company that's under NDA for everything?
Describe the work generically. "Redesigned onboarding for a B2B SaaS product; completion improved 25%" works without naming specifics. You don't need to show the actual designs if you can articulate your process, decision-making, and impact. Some interviewers may ask to see work under NDA if you sign an NDA with them, but you can interview successfully on descriptions alone.
Should I demonstrate live in Figma during the interview?
Only if the interviewer asks. Most prefer you walk through your portfolio and then open Figma if questions come up. Live demo risk: slow performance, awkward navigation, losing your place. Rehearsed walkthrough is smoother. But being able to open Figma and show how you built something (components, constraints, prototyping) is a useful backup if they want to dig deeper.