UI Designer Interview Questions (2026) and How to Answer

Behavioural questions (1–10)

How you've handled real situations. Answer each with one true story, in STAR order.

1. 1.Walk me through a project in your portfolio from brief to final screens.

   What they're really asking: Can you narrate your process clearly, not just show pretty pictures?

   Answer outline (STAR)

   • SituationA screen or flow you were asked to design from a loose brief.
   • TaskTurn the brief into a usable, on-brand interface.
   • ActionClarify requirements, sketch options, test layouts against the brand system, refine with feedback.
   • ResultThe shipped design, and one thing you'd change if you redid it.

   Full sample answer (fictional example)

   A retail client asked for a simpler checkout flow after seeing drop-off at the payment step. I clarified with the PM which step specifically lost users, then sketched three layout options reducing the number of fields visible at once. I tested the top two with five users informally, picked the clearer one, and matched it to the existing design system's components and spacing. After a round of engineering feedback on feasibility, I adjusted the error-state design slightly and handed off annotated files. The flow shipped, and checkout completion rose in the first month. If I redid it, I'd test the error states with users too, not just the happy path.

2. 2.Tell me about a time a stakeholder rejected your design direction.

   What they're really asking: Can you handle disagreement without just complying or digging in?

   Answer outline (STAR)

   • SituationA director or PM who preferred a different visual direction than yours.
   • TaskReach a design that served the goal, not just your preference.
   • ActionAsk what concern was behind the objection, show alternatives side by side, test if time allowed.
   • ResultThe direction chosen, and what you learned about their priorities.

   Full sample answer (fictional example)

   A marketing director wanted a bolder, more colorful homepage than the direction I'd designed. Instead of arguing for my version outright, I asked what outcome she wanted the color to create, and she said she wanted the page to feel more energetic to new visitors. I built two alternatives at different intensity levels using our existing palette and showed them side by side with her original ask in mind. We picked a middle option together that felt more energetic without breaking brand consistency. I learned she cared more about the feeling than the specific colors, which changed how I framed later proposals to her.

3. 3.Describe a time you had to design within a strict design system.

   What they're really asking: Do you work well inside constraints instead of fighting them?

   Answer outline (STAR)

   • SituationA component library that didn't have the pattern a new feature needed.
   • TaskSolve the need without breaking consistency.
   • ActionSearched existing components for a close match, proposed a small variant, got it approved by the system owner.
   • ResultThe variant adopted into the library, and how it got reused later.

   Full sample answer (fictional example)

   A new onboarding feature needed a stepped progress indicator, but our component library had no such pattern. Rather than inventing something unrelated, I looked through existing components and found a tab bar whose structure was close to what I needed. I proposed a variant that reused the same spacing and color tokens but adjusted the states for active, completed and upcoming steps. The system owner reviewed it, approved it with minor tweaks to the completed-state icon, and it went into the shared library. Two other teams later reused that same component for their own onboarding flows.

4. 4.Tell me about giving critical feedback to another designer's work.

   What they're really asking: Can you critique work usefully without being harsh or vague?

   Answer outline (STAR)

   • SituationA teammate's draft with a layout that would confuse users.
   • TaskImprove the work while keeping the relationship intact.
   • ActionLed with what worked, named the specific confusion, suggested two alternatives rather than one fix.
   • ResultThe revision made, and how the designer reacted to the feedback.

   Full sample answer (fictional example)

   A teammate drafted a settings page where related options were scattered across three tabs with no clear logic. I started by noting what worked well, like the clean visual style, then pointed out specifically that users would likely not expect account and privacy settings to be split apart. Instead of just telling her to fix it, I sketched two alternative groupings and asked which matched her intent better. She picked one, reorganized the tabs, and the page tested more clearly with users afterward. She later told me she appreciated getting options rather than just a correction.

5. 5.Tell me about a design you shipped that didn't perform as expected.

   What they're really asking: Do you treat your own designs as hypotheses, not certainties?

   Answer outline (STAR)

   • SituationA redesigned flow you expected to increase completion.
   • TaskLearn why it underperformed and correct course.
   • ActionReviewed session recordings and analytics, found the actual drop-off point, proposed a targeted fix.
   • ResultThe metric after the fix, and the assumption you stopped trusting blindly.

6. 6.Tell me about a time you pushed back on a request from a product manager.

   What they're really asking: Can you advocate for the user without being difficult to work with?

   Answer outline (STAR)

   • SituationA PM who wanted a feature crammed into an already busy screen.
   • TaskProtect the user experience while still meeting the business need.
   • ActionProposed an alternative layout and showed how the crowded version hurt scannability.
   • ResultThe PM agreed to the alternative, and the feature still shipped on time.

7. 7.Describe a time you had to design for a user group very different from yourself.

   What they're really asking: Do you design from evidence about users, not personal assumption?

   Answer outline (STAR)

   • SituationA product used mainly by people over 60 with little tech experience.
   • TaskMake the interface genuinely usable for that group.
   • ActionReviewed usability sessions with that group, simplified language and increased touch target sizes.
   • ResultCompletion rate for that group improved, confirmed in a follow-up test.

8. 8.Tell me about a time you had to defend a design decision with data.

   What they're really asking: Can you back up intuition with evidence when challenged?

   Answer outline (STAR)

   • SituationA stakeholder who doubted a navigation change you'd made.
   • TaskProve the change actually helped rather than just arguing opinion.
   • ActionPulled click-through and task-completion data from before and after the change.
   • ResultThe data supported the change, and the stakeholder stopped contesting similar decisions.

9. 9.Tell me about a time you had to learn a new tool or skill quickly for a project.

   What they're really asking: How fast can you adapt when a project demands something new?

   Answer outline (STAR)

   • SituationA project requiring motion design skills you hadn't used before.
   • TaskDeliver credible animated transitions on a tight deadline.
   • ActionStudied tutorials, prototyped in the tool evenings, asked a motion specialist for one review pass.
   • ResultThe transitions shipped on time, and you kept using the skill after.

10. 10.Tell me about receiving harsh critique on your work.

    What they're really asking: Can you take tough feedback professionally and use it?

    Answer outline (STAR)

    • SituationA senior designer who called an early draft confusing in a group review.
    • TaskTurn blunt feedback into a better design rather than getting defensive.
    • ActionAsked clarifying questions instead of reacting, then revised based on the specific points raised.
    • ResultThe revised version was approved, and you adopted that reviewer's habit of checking first drafts early.

Technical and role-skill questions (11–22)

Can you do the work itself? Think out loud and name the trade-offs.

1. 11.What makes a design system effective across a large product?

   What they're really asking: Do you understand systems thinking, not just individual screens?

   Answer outline

   • Reusable components with clear states cover most common needs.
   • Design tokens for color, spacing and type keep consistency as the product grows.
   • Documentation of when and why to use each component prevents drift.

   Full sample answer (fictional example)

   I think an effective design system rests on reusable components with clearly defined states, like default, hover, disabled and error, so designers aren't rebuilding basics each time. Underneath that, shared tokens for color, spacing and typography keep visual consistency as the product scales across many screens and teams. Just as important is documentation explaining when and why to use each component, not only how it looks, since teams without that context tend to misuse patterns or build duplicates. I've seen systems fail not from lacking components but from lacking the reasoning behind them, so new designers guess instead of checking.

2. 12.How do you decide on type scale and spacing for an interface?

   What they're really asking: Can you justify visual decisions with a system, not just taste?

   Answer outline

   • Start from a base unit and a modular scale for predictable sizing steps.
   • Set a small number of type sizes and weights tied to clear roles like heading or body.
   • Test spacing at real content lengths, not just placeholder text.

3. 13.How do you design for accessibility in a UI?

   What they're really asking: Do you build inclusive interfaces as a default, not an afterthought?

   Answer outline

   • Check color contrast ratios against WCAG guidelines for text and icons.
   • Design visible focus states and a logical tab order for keyboard use.
   • Don't rely on color alone to convey status; pair it with text or icons.

   Full sample answer (fictional example)

   I check color contrast ratios against WCAG guidelines for both text and icons early, since fixing that after visual design is set is much harder. I design visible focus states and make sure tab order follows a logical reading path for keyboard users, which is often skipped until QA flags it. I also avoid relying on color alone to show status, like a red dot for an error, and pair it with text or an icon so colorblind users aren't left guessing. On a recent project this caught an error state that was invisible to about eight percent of test users before it ever shipped.

4. 14.Walk me through how you'd hand off a design to engineering.

   What they're really asking: Do you understand what developers actually need from you?

   Answer outline

   • Annotate spacing, states and breakpoints directly in the file.
   • List edge cases: empty states, long text, loading and error states.
   • Stay available during build for questions rather than disappearing after handoff.

5. 15.How do you choose between a modal, a drawer and a full page for a new flow?

   What they're really asking: Can you match UI patterns to context instead of defaulting to habit?

   Answer outline

   • A modal suits a quick, focused task that doesn't need the full page context.
   • A drawer works well for supplementary detail alongside the main content.
   • A full page suits a long or multi-step task that deserves its own URL.

6. 16.What's your process for designing an empty state?

   What they're really asking: Do you treat edge cases as real design problems, not filler?

   Answer outline

   • Explain what the screen will show once there's content.
   • Give the user a clear next action, like a button to create their first item.
   • Avoid a blank screen that looks broken rather than simply empty.

7. 17.How do you use Figma components and variants to stay efficient?

   What they're really asking: Tool fluency, since most teams run on Figma day to day.

   Answer outline

   • Build components with variants for states like default, hover, disabled and error.
   • Use auto layout so components resize predictably with real content.
   • Keep a single source file for shared components instead of duplicating them.

8. 18.How do you build and maintain visual consistency across a large product?

   What they're really asking: Do you understand systems-level thinking versus screen-by-screen design?

   Answer outline

   • Define shared tokens for color, spacing and typography that every screen pulls from.
   • Audit new screens against the system regularly to catch drift early.
   • Update the system itself, not just individual screens, when a real gap is found.

9. 19.What's your approach to designing responsive layouts across breakpoints?

   What they're really asking: Can you design for real screen variety, not just one canvas size?

   Answer outline

   • Start from the most constrained viewport and work up, or use a flexible grid from the start.
   • Define clear rules for how components reflow, stack or hide at each breakpoint.
   • Test with real content lengths, since placeholder text hides most layout problems.

10. 20.How do you choose a color palette that works for both light and dark mode?

    What they're really asking: Do you understand color systems beyond picking shades that look nice?

    Answer outline

    • Define semantic color roles, like surface or border, rather than hardcoding specific hues.
    • Check contrast ratios separately for each mode rather than assuming one palette works for both.
    • Test the palette against real content, since some colors shift perception next to others.

11. 21.How do you prototype an interaction before it's built?

    What they're really asking: Can you communicate motion and behavior, not just static layout?

    Answer outline

    • Use a tool like Figma's prototyping mode or a motion tool for key transitions.
    • Keep the prototype focused on the one interaction in question, not the whole flow.
    • Share it early with engineering to confirm feasibility before investing more polish.

12. 22.How do you evaluate whether a UI pattern from another product is worth reusing?

    What they're really asking: Can you borrow patterns thoughtfully instead of copying trends?

    Answer outline

    • Check whether the context and user goal actually match your own product.
    • Consider whether your users already have a mental model from that other product.
    • Adapt the pattern to your design system rather than pasting it in unchanged.

Take-home or live exercise: tips

UI designer interviews often include a timed whiteboard or Figma exercise redesigning a small screen, plus a portfolio critique where you defend specific decisions.

• Narrate your reasoning out loud as you sketch, since the thinking matters more than the final polish.
• Ask clarifying questions about the user and goal before jumping into layout.
• Reference your design system instincts even without an actual library in front of you.
• In a portfolio review, be ready to explain a decision you'd now make differently.

Situational questions (23–30)

Scenarios that test judgement: say what you'd do first, and why.

1. 23.Engineering tells you a design isn't feasible in the current sprint. What do you do?

   What they're really asking: Can you negotiate scope without just caving or stalling the release?

   Answer outline

   • Ask what specifically is hard: the interaction, the animation or the layout.
   • Propose a simplified version that ships now, with the full version staged for later.
   • Keep the core user goal intact even if the polish is reduced.

   Full sample answer (fictional example)

   I start by asking what specifically is hard: is it the interaction, the animation, or the layout structure itself, since those have very different fixes. Once I understand the real constraint, I propose a simplified version that keeps the core user goal intact but trims the part that's expensive to build right now. For example, I once swapped a custom animated transition for a simpler fade when a deadline was tight, and staged the fuller version for the next release. I make sure the simplified version doesn't quietly become permanent by logging it clearly as a follow-up task.

2. 24.A client or executive says they 'just don't like' your design, with no specifics. How do you respond?

   What they're really asking: Can you extract usable feedback from a vague reaction?

   Answer outline

   • Ask what feeling they expected the design to create, and where it falls short.
   • Walk through the goals the design was meant to meet and check those against their reaction.
   • Offer two revised directions rather than guessing at one.

   Full sample answer (fictional example)

   I ask what feeling or outcome they expected the design to create, since that question usually surfaces something concrete even when the first reaction was vague. Once, an executive said a dashboard 'felt cluttered' with nothing more specific; asking what he wanted to find quickly revealed he couldn't locate the one number he checked daily. I walked through the goals the design was meant to meet and checked them against his reaction, then offered two revised layouts that surfaced that number more prominently rather than guessing at a single fix. He picked one immediately once he saw it addressed his actual concern.

3. 25.Your design is visually strong but usability testing shows users are confused. What do you do?

   What they're really asking: Will you prioritize clarity over visual polish when they conflict?

   Answer outline

   • Look closely at where in the flow the confusion happens and why.
   • Simplify the layout or copy even if it means a less striking visual.
   • Retest the simplified version to confirm it actually fixed the confusion.

   Full sample answer (fictional example)

   I look closely at exactly where in the flow the confusion happens, since that's usually more specific than the general comment users give in a session. On a settings redesign, users loved the visual style but consistently missed a save button buried under an icon with no label. I added a text label and moved it to a more expected position even though it made that corner less visually minimal. Retesting the simplified version confirmed users found it immediately, which told me the fix actually worked rather than just feeling resolved.

4. 26.A marketing deadline requires shipping a screen before you're fully happy with it. What do you do?

   What they're really asking: Can you ship pragmatically without lowering your bar permanently?

   Answer outline

   • Identify what's actually broken versus merely not ideal.
   • Fix anything that would confuse or block users, and let polish wait if needed.
   • Log the deferred improvements so they don't get forgotten after launch.

   Full sample answer (fictional example)

   I separate what's actually broken, meaning it would confuse or block users, from what's simply not as polished as I'd like. On one launch, a promotional page had a secondary animation I hadn't perfected, but the core layout and copy worked fine, so I shipped it as is and fixed the animation in a follow-up release two weeks later. I logged the deferred work clearly in our tracker so it wouldn't get forgotten once attention moved elsewhere. Shipping something solid but imperfect on time mattered more here than holding the whole page back for one detail.

5. 27.A rebrand changes the color palette halfway through a project. How do you handle it?

   What they're really asking: Can you adapt an in-progress project without losing momentum?

   Answer outline

   • Assess which screens are affected and which can wait until after launch.
   • Update shared components first so changes propagate instead of manual fixes everywhere.
   • Communicate the delay, if any, clearly to stakeholders waiting on the original timeline.

6. 28.You discover a usability issue in a screen that already shipped. What do you do?

   What they're really asking: Will you flag your own past work rather than let it slide?

   Answer outline

   • Confirm the issue with data or a quick user check before raising it.
   • Report it to the team with its likely impact rather than quietly patching it alone.
   • Propose a fix and a rough timeline based on its severity.

7. 29.A user research session reveals your design assumption was wrong. How do you respond?

   What they're really asking: Can you let evidence override your own prior work?

   Answer outline

   • Separate your attachment to the design from what the session actually showed.
   • Identify exactly which assumption failed and why, rather than scrapping everything.
   • Revise the design and plan a quick follow-up check before wider rollout.

8. 30.You're asked to design a feature you personally think is a bad idea for users. What do you do?

   What they're really asking: Can you raise concerns professionally and still deliver if overruled?

   Answer outline

   • State the concern clearly with the specific user risk you see.
   • Offer an alternative that meets the business goal with less user cost.
   • If overruled, design it as well as you can and flag what to monitor after launch.

Red flags to avoid in your answers

Each one is quick to fix before the day.

1. Showing only final screens with no process or reasoning.

   Narrate the decisions behind each major screen, not just the outcome.

2. Treating feedback as a personal attack rather than useful input.

   Describe a time critique changed your design for the better.

3. Designing without checking the existing system or patterns.

   Explain how you audit for consistency before proposing something new.

4. Prioritizing visual polish over clarity when the two conflict.

   Show an example where you simplified a design after usability data.

How to prepare for an UI designer interview in 7 days

An hour or two a day is enough; the order matters more than the length.

1. 1

   Day 1: Portfolio script

   Write out the exact story, in order, for each of your three strongest portfolio pieces.

2. 2

   Day 2: System audit

   Pick a product you use daily and list three inconsistencies you'd fix in its design system.

3. 3

   Day 3: Timed exercise

   Redesign one small screen in Figma under a 30-minute timer to build exercise speed.

4. 4

   Day 4: Accessibility pass

   Run a contrast checker and keyboard-only test across one of your portfolio pieces.

5. 5

   Day 5: Handoff review

   Annotate one of your Figma files as if handing it to an engineer who's never seen it.

6. 6

   Day 6: Feedback rehearsal

   Practice responding out loud to vague feedback like 'make it pop' with clarifying questions.

7. 7

   Day 7: Feedback rounds

   Review a stranger's public design work and write feedback that leads with what works.

Questions to ask the interviewer

Pick two or three; the answers tell you whether you want the job.

1. What does the design system look like, and who maintains it?
2. How closely do designers work with engineers during the build phase?
3. How are design decisions tested, if at all, before they ship?
4. What tools does the team use for design, prototyping and handoff?
5. What's an example of a design that shipped and clearly moved a metric?

Preparation tips

• Rehearse your portfolio walkthrough out loud so the story, not just the screens, is tight.
• Review the company's product closely beforehand and note any UI inconsistencies you'd fix.
• Practice a quick Figma redesign exercise under a time limit before the interview.
• Bring examples of feedback you received and how your design changed because of it.

Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.