UI Designer Interview Questions and Answers

Preparing for a UI Designer interview means more than rehearsing generic answers. You need to demonstrate your design philosophy, show how you think through problems, and prove you understand that great UI design is about solving real user problems—not just making things look good. This guide walks you through the most common UI Designer interview questions and answers, giving you frameworks you can adapt to your own experience.

Common UI Designer Interview Questions

”Walk me through your design process from start to finish.”

Why they ask: This question reveals your methodology, whether you’re user-centered, how you validate decisions, and if you can communicate your thinking clearly. It’s one of the most important questions because it shows how you approach work day-to-day.

Sample answer:

“I always start by understanding the problem and the user. Before I open any design tool, I dive into user research—talking to stakeholders, reviewing analytics, and when possible, interviewing actual users. I map out user flows and create personas to anchor my thinking.

From there, I move into low-fidelity wireframes to explore the information architecture and core interactions. I share these early sketches with the team to get feedback and validate assumptions before investing time in high-fidelity work.

Once the wireframes are validated, I create detailed mockups in Figma, building out the visual design system, typography, colors, and components. I prototype key interactions so developers understand the intended behavior, and I conduct user testing on the prototype to catch usability issues before handoff.

Throughout this process, I iterate based on feedback. The design never feels ‘done’—it’s always evolving based on what we learn.”

Tip for personalizing: Replace Figma with your tool of choice, and swap in a real project from your portfolio. Mention specific methods you’ve used—like tree testing, heatmaps, or A/B testing—if they apply to your experience.

”How do you handle conflicting feedback from stakeholders?”

Why they ask: UI Designers work with multiple opinions from product managers, engineers, executives, and users. They want to know if you can navigate disagreement professionally and prioritize what matters most.

Sample answer:

“I start by listening to everyone’s perspective without getting defensive. Usually, behind conflicting opinions there’s a shared goal—we just disagree on the approach. I ask clarifying questions: What’s the underlying concern? How does this tie to user needs or business goals?

Then I try to reframe the conversation around data and user impact. I might say, ‘I hear both concerns. Let me run a quick user test to see which approach feels more intuitive.’ Or I’ll propose a compromise that addresses the core concern from each stakeholder.

I’ve learned that sometimes the best outcome isn’t my original design idea—it’s a solution we landed on together. In a recent project, the product lead wanted a more complex filtering system, but I was concerned it would overwhelm users. We ran a 30-minute user test with a prototype and watched users struggle with both approaches. That evidence helped us land on a middle ground that worked better than either of our initial ideas.”

Tip for personalizing: Choose a real example where you changed your mind or where the team’s feedback improved the outcome. Avoid sounding like you always ‘won’ the argument.

”Tell me about a design project you’re most proud of and why.”

Why they ask: Beyond evaluating your portfolio, they want to understand what you value in design, how you measure success, and whether your priorities align with theirs.

Sample answer:

“I’m really proud of a project where I redesigned the onboarding flow for a SaaS tool. On the surface, it was about simplifying the signup process, but the real win was that I cut the time to first value from 15 minutes to under 3 minutes.

Here’s what made me proud: I didn’t just make it ‘prettier.’ I sat through actual user sessions and watched where people got confused. They were spending most of their time filling out unnecessary profile information. So I restructured the entire flow to let users get into the product first, then progressively ask for more details as they needed features.

The visual design was cleaner too—better use of white space, clearer affordances—but the real impact was on the business metrics. We saw a 40% improvement in signup-to-activation rates. That’s when I realized that the best design work isn’t about aesthetics; it’s about removing friction and helping users accomplish their goals.”

Tip for personalizing: Pick a project where you can connect design decisions to measurable outcomes—whether that’s engagement metrics, user satisfaction scores, or user feedback. Show both the ‘why’ behind your decisions and the impact.

”How do you approach responsive design across different devices?”

Why they ask: UI Designers need to create interfaces that work seamlessly on mobile, tablet, and desktop. This reveals whether you understand platform differences and can prioritize effectively within constraints.

Sample answer:

“My approach is mobile-first. I start by designing for the smallest screen, which forces me to prioritize what’s essential. Once I’ve nailed the mobile experience, I can expand the layout for larger screens without just stretching everything out.

For mobile, I focus heavily on thumb-friendly touch targets—I aim for at least 44x44 pixels for tappable elements. I simplify navigation, often using bottom tabs or hamburger menus. I also think about screen orientation and make sure the experience doesn’t break when someone rotates their phone.

For tablet, I have a bit more breathing room, so I can show more information at once. For desktop, I can introduce hover states, more complex layouts, and additional features that wouldn’t make sense on mobile.

The key is that I’m not just resizing things. I’m rethinking the interaction model for each screen size. In my last project, the desktop version had a sidebar for navigation, but on mobile, that became a bottom tab bar. It’s not just about fitting things on screen—it’s about what makes sense for how people use each device.”

Tip for personalizing: Mention whether you design in one tool or jump between tools for different breakpoints. Call out specific decisions you’ve made—like changing navigation patterns or reorganizing content—not just scaling.

”What’s your experience with design systems, and how do you contribute to them?”

Why they ask: Design systems are increasingly important in organizations managing multiple products or platforms. They want to know if you can think beyond one-off projects and contribute to scalable, consistent design work.

Sample answer:

“I’ve worked with design systems in most of my recent roles, and I think they’re crucial for maintaining consistency and scaling design across a team. In my last position, we had a pretty basic component library, and I helped expand it by auditing all the different button styles, form inputs, and modals we were using across the product.

I standardized these into a formal set of components with clear documentation—things like what variations existed, when to use each one, and what the interaction states should be. I created a Figma file that designers could use as a source of truth, and I worked with engineering to make sure the code implementation matched the design.

The thing I’ve learned is that a design system only works if people actually use it. So I spent time getting feedback from other designers, refined the components based on what was working and what wasn’t, and created documentation that was actually useful—not just a list of specs.

Now we’re thinking about tokens for spacing, colors, and typography, so we can scale even further and make global changes without touching every design file.”

Tip for personalizing: Be specific about your role—did you build the system from scratch, or extend an existing one? What tools and processes did you use? Mention challenges you faced and how you overcame them.

”How do you stay current with design trends and tools?”

Why they asks: Design evolves quickly. They want to know you’re learning continuously and can thoughtfully apply new trends—not just copying what’s trendy.

Sample answer:

“I stay current through a mix of things. I follow design blogs like Smashing Magazine and Designer Hangout, and I’m pretty active on design Twitter and LinkedIn. I also listen to podcasts during my commute—UX Podcast and Design Observer are favorites.

But here’s what’s important: I don’t just consume trends. I evaluate them critically. When I see a design trend gaining traction, I ask myself, ‘Does this solve a real problem, or is it just aesthetic?’ For example, neumorphism looked cool, but I concluded it actually hurt usability because it was harder to identify clickable elements.

I also invest in learning new tools. I used to work exclusively in Sketch, but I’ve moved to Figma because of the collaboration features. I spent a weekend learning it properly and now I’m much faster in it than I was in Sketch.

Recently, I completed a course on accessibility design. That’s not a ‘trend’ exactly, but it’s an evolving area where I want to stay sharp. I think the best learning isn’t always about the flashy new tool—it’s about deepening skills in areas that’ll make me a better designer.”

Tip for personalizing: Mention 2–3 specific resources you actually use, not a generic list. Share a specific trend you evaluated and explain why you did or didn’t adopt it.

”Describe your experience with accessibility in UI design.”

Why they ask: Accessibility is non-negotiable in modern design. This question tests your understanding of WCAG guidelines, your commitment to inclusive design, and whether you’ve actually implemented accessible solutions.

Sample answer:

“Accessibility isn’t an afterthought for me—it’s baked into my process from the beginning. I start by understanding the WCAG guidelines, and I aim for at least AA compliance on every project.

In terms of practical implementation, I’m careful about color contrast. I use tools like WebAIM’s contrast checker to ensure text is readable. I never rely on color alone to communicate information—if something is red to indicate an error, it also has an icon or text label.

I design for keyboard navigation, making sure interactive elements are in a logical tab order. I test this regularly by navigating through a prototype using only the keyboard. I also think about focus states—they need to be visible and clear so keyboard users know where they are.

For images and icons, I work closely with developers on alt text. I sometimes create alt text specs in my design handoff to make sure it’s descriptive enough. And I do preliminary accessibility testing with tools like Axe, though I know automated testing only catches maybe 30% of issues.

In a recent project, I redesigned a data dashboard, and I made sure charts weren’t just visual—I added data tables as alternatives for screen reader users. It took more time, but it meant the product was actually usable for everyone.”

Tip for personalizing: Mention specific WCAG guidelines you follow and actual tools you use. Better yet, describe a project where accessibility led to a better design for everyone, not just people with disabilities.

”How do you collaborate with developers and engineers?”

Why they ask: Designers who can’t work well with engineering are a problem. They want to know if you understand technical constraints, communicate clearly, and respect the implementation phase.

Sample answer:

“I’ve learned that the best designs come from collaboration with engineers, not designs handed over a wall. I try to involve engineers early—sometimes even in the wireframing phase—so they can flag technical constraints I might not have considered.

When I hand off a design, I’m really detailed in my Figma file. I create a spec that shows spacing, sizing, colors, interactions—everything a developer needs to build accurately. I use naming conventions for components and layers so it’s easy to navigate. I include interactions and micro-animations with notes about timing and easing functions.

But I also stay involved after handoff. I do QA on the built product to catch discrepancies. Sometimes developers will come back with questions about how something should behave, and I’d rather have that conversation than have them guess.

I’ve also learned to appreciate when an engineer pushes back. Sometimes I’ll propose an interaction that’s technically complex or performance-heavy, and when an engineer explains the tradeoff, I’m happy to find a simpler alternative that achieves the same goal for the user. It’s not about me being ‘right’—it’s about building the best product together.”

Tip for personalizing: Mention a specific tool or process you use for handoff (Figma specs, Zeplin, whatever you actually use). Share an example where an engineer’s feedback improved the design.

”Tell me about a time you had to learn a new tool quickly.”

Why they ask: Design tools keep changing. They want to know if you can adapt, learn independently, and aren’t wedded to any one tool.

Sample answer:

“When I started my last role, the team was using Figma, which I’d only used casually. The project timeline was tight, so I knew I had to get up to speed fast.

I spent a weekend going through the Figma tutorials and practicing with a dummy project. I focused on the features I’d use most—components, auto-layout, and prototyping. Then I just jumped in on the real project. I moved slower those first few days than I would have in Sketch, but I was honest with my team about it and asked for help when I needed it.

What really helped was that Figma’s collaborative features immediately made sense to me—I could see the value. That motivated me to learn it properly. Within a couple of weeks, I was as efficient as I’d been in Sketch, and honestly, I’m faster now.

The lesson I learned is that as long as you understand design fundamentals, the tool is just a tool. I’m not afraid to pick up something new because I know the principles transfer.”

Tip for personalizing: Pick a tool you actually learned and mention how long it took to become proficient. Emphasize that you learned independently and what motivated you to do so.

”How do you measure the success of your design work?”

Why they ask: This reveals whether you think about impact, understand business metrics, and can evaluate your own work critically.

Sample answer:

“I measure success on a few levels. First, does it solve the user problem? I look at user feedback, analytics, and qualitative testing. If I redesigned a checkout flow, are users completing purchases more easily? If I redesigned navigation, are users finding what they need faster?

Second, does it align with business goals? If we wanted to reduce support tickets, and post-redesign we see a 20% drop, that’s a win. If we wanted to increase feature adoption, and certain features are now used more frequently, that’s data that the design worked.

Third, I think about internal feedback. Are the team and stakeholders satisfied? Is engineering able to build this effectively? Are there technical debt or scalability issues?

I’m also honest when something doesn’t work as well as I hoped. I had a project where I redesigned the dashboard with a new layout I was really proud of aesthetically, but usage data showed users were actually slower at finding information. That was a reality check. I iterated based on that feedback, and the second version performed better.

The best metric depends on the project. Sometimes it’s about engagement, sometimes conversion, sometimes learning velocity for new users. I try to define success metrics at the start so I’m not just guessing whether something worked.”

Tip for personalizing: Mention specific metrics you’ve tracked—conversion rates, time-on-task, NPS scores, whatever applies to your work. Include a failure that taught you something.

”What would you do if you discovered a design flaw post-launch?”

Why they ask: Things go wrong. They want to know if you’ll own mistakes, communicate transparently, and take action to fix them rather than make excuses.

Sample answer:

“This has actually happened to me. We launched a redesigned account settings page, and within a week, we started seeing error reports and support tickets from users who couldn’t find the password reset option.

When I dug into it, I realized the visual hierarchy was off. The button wasn’t prominent enough, and I’d hidden it below other settings that users didn’t need to access as often. Mistakes happen, especially when you’re working at speed.

I immediately flagged it with my team and product manager. We discussed whether a quick patch or a more thorough redesign made sense. In this case, a quick fix was appropriate—I increased the visual prominence of the button, made the section title clearer, and we shipped it within a couple of days.

But I also did a retrospective. Why did this get through testing? I should have done more usability testing on that specific workflow. I added password reset to my test scenarios for future projects.

I didn’t make excuses or blame the testing team. I took ownership, communicated what I’d learned, and made sure it didn’t happen again.”

Tip for personalizing: Be honest about a real mistake you’ve made, not a hypothetical. Focus on how you identified it, owned it, and improved the process.

”How do you approach designing for different user segments or personas?”

Why they ask: Most products serve multiple types of users with different needs. They want to know if you can balance competing requirements and design for nuance, not a one-size-fits-all approach.

Sample answer:

“I always start by understanding who our users actually are. I build personas based on real data—user research, analytics, interviews—not assumptions. These personas include not just demographics, but goals, pain points, and how they’d use the product differently.

In one project, I was designing a project management tool, and we had two main personas: busy executives who just wanted a quick status view, and detailed-oriented project managers who needed all the data. On the surface, these seem contradictory, but they weren’t. The solution was progressive disclosure.

I designed the default view to show executives what they cared about—key milestones and status. But power users could click into more detailed views. We used a toggle that let users customize what they see by default. So both segments got what they needed without overwhelming the interface.

I also test with actual users from different segments, not just one type. If I’m designing for both mobile users and desktop users, or for both experts and novices, I make sure I’m testing with representatives from each group. That helps catch situations where an optimization for one persona actually hurts another.”

Tip for personalizing: Reference actual personas from a project you worked on and describe how you balanced their needs in the design. Mention a specific feature or pattern you used to serve multiple user types.

”Tell me about a time you had to push back on a design request from a stakeholder.”

Why they ask: They want to know if you have conviction about design decisions and can advocate for users, not just follow orders.

Sample answer:

“A few months ago, the CEO of the company came to our team with a request to add a new widget to the product dashboard. It looked cool and showcased some new data we were collecting. The feature request came from the top, so there was pressure to include it.

But I started thinking about the user. The dashboard was already information-dense, and adding another widget would make it worse. So I decided to test it. I created a prototype with the new widget and ran user testing with five actual power users.

They were unanimous: the dashboard was overwhelming, and they couldn’t figure out which widget had the information they needed. I brought this data back to the CEO and framed it as, ‘Users are struggling to find what they need. Before we add more, we should simplify what’s there.’

We ended up doing a dashboard redesign that prioritized the most important information, removed clutter, and then found a good home for the new widget. It took a bit longer than just adding the widget, but the result was better for users and for the business.

The lesson I learned is that having data and user insight made it much easier to have that conversation. I wasn’t just saying ‘I don’t like it.’ I was saying, ‘Users are struggling with this,’ which is a conversation we can have together.”

Tip for personalizing: Choose a real example where you used research or testing to back up your position. Emphasize that you weren’t being difficult—you were advocating for users.

”What design tools do you use, and why do you prefer them?”

Why they ask: This reveals how you work and whether you’re adaptable. It also helps them understand if you already know their tools.

Sample answer:

“I primarily work in Figma now. I love the collaborative features—multiple people can work in the same file, and the real-time collaboration is seamless. For me, that translates to fewer meetings and async feedback. I can work on something, share it with the team, and they can jump in and leave comments or suggestions.

The component system is also really powerful. I can create a button component once, and when I update it, it updates everywhere it’s used. That’s huge for consistency and for scaling design systems.

For prototyping, I use Figma’s built-in interactions for most projects. It’s good enough to communicate intended behavior to developers and for user testing. For more complex, code-like interactions, I’ve used Framer, though I don’t reach for it often.

For design thinking and brainstorming, I honestly still sketch on paper or use a whiteboard. There’s something about the low-fidelity, imprecise nature of sketching that helps me explore ideas without getting bogged down in details.

I’m also comfortable with other tools. If a team uses Adobe XD or Sketch, I can switch. I don’t think any one tool is objectively ‘best’—it’s about what the team uses and what makes sense for the project.”

Tip for personalizing: Be specific about what you like and don’t like about your tools. If you use multiple tools, explain why you use each one. Avoid speaking badly about other tools.

”How do you handle a situation where a deadline is impossible and design quality would suffer?”

Why they ask: Deadlines are real, but so is design quality. They want to know if you communicate proactively, propose realistic solutions, and don’t deliver bad work just to meet arbitrary dates.

Sample answer:

“I’ve definitely faced this. A few months ago, we had a product launch planned, and engineering was hitting some roadblocks. They could still hit the launch date, but only if design was done two weeks earlier than originally planned. That timeline was unrealistic for the quality of work we needed.

Instead of just complaining, I proposed a scope adjustment. I said, ‘Here’s what we can do really well in that timeline, and here’s what should ship in v2. Let’s get the core experience right and iterate on the rest.’

We cut some secondary features and screens from the first release. We focused on the main user flows. It meant the initial launch was tighter than planned, but the quality was there.

The trick is doing this early. I flagged this as soon as I realized the timeline was problematic, maybe three weeks before the deadline. If I’d waited until a week before to say something, the team would have been in crisis mode. Early communication gives everyone options.

I’ll do my best to hit deadlines, but I won’t sacrifice quality to do it. My reputation is tied to the work I ship, so I’d rather have a hard conversation about scope or timeline than ship something I’m not proud of.”

Tip for personalizing: Describe a real situation where you managed timeline pressure, what you communicated, and what actually happened. Show that you’re pragmatic, not perfectionist.

Behavioral Interview Questions for UI Designers

Behavioral questions ask about past situations to predict how you’ll behave in the future. Use the STAR method: Situation, Task, Action, Result. Set the scene briefly, explain what you needed to accomplish, describe what you actually did, and tell them the outcome. Keep each answer to about 2 minutes.

”Tell me about a time you had to work with a difficult team member or stakeholder.”

STAR framework:

• Situation: What was the relationship strained over? Was it a creative disagreement, a communication issue, or conflicting priorities?
• Task: What outcome were you trying to achieve?
• Action: What specific steps did you take to improve the relationship or resolve the conflict? Did you ask questions to understand their perspective? Did you involve a mediator? Did you change your approach?
• Result: How did the situation resolve? Did the project benefit? Did the relationship improve?

Tip: Show emotional intelligence. Don’t vent about how difficult they were. Explain what you learned about communicating differently.

”Describe a project where you had to work outside your comfort zone.”

STAR framework:

• Situation: What was unfamiliar? A new industry, tool, type of design, or user audience?
• Task: What did you need to deliver?
• Action: How did you approach learning? Did you research, ask for help, take a course, or just dive in? What was the process?
• Result: What did you accomplish? What did you learn?

Tip: Emphasize your learning agility and willingness to grow. Pick something genuinely outside your experience, not something you already knew.

”Tell me about a time you received critical feedback on your work. How did you respond?”

STAR framework:

• Situation: What was the feedback? Who gave it? Was it in a formal review, during a critique, or informal?
• Task: You needed to improve and maintain the relationship.
• Action: Did you ask clarifying questions? Did you take time to process? Did you implement the feedback, or did you have a discussion about it first?
• Result: How did you change? Did the relationship improve? Did the work improve?

Tip: Show that you don’t get defensive. Be specific about the feedback and how it changed your thinking.

”Describe a time you had to prioritize multiple projects with competing deadlines.”

STAR framework:

• Situation: How many projects? What were the deadlines? What were the stakes?
• Task: You needed to deliver quality work on multiple fronts without burning out.
• Action: How did you organize yourself? Did you create a timeline, communicate with stakeholders about expectations, delegate, or work overtime? What systems or tools did you use?
• Result: Did you meet the deadlines? Did quality suffer? How did you feel about it?

Tip: Show your organizational and communication skills. Mention any processes you put in place that could help in the future.

”Tell me about a time you had to adapt your design based on user feedback.”

STAR framework:

• Situation: What kind of feedback? How did you get it? User testing, analytics, support tickets, interviews?
• Task: You needed to improve the design while respecting the work already done.
• Action: What changes did you make? How did you prioritize which feedback to act on? Did you test your changes?
• Result: How did users respond to the updated design? Did metrics improve?

Tip: Show that you’re data-driven and user-focused, not ego-invested in your original design.

”Describe a situation where you had to explain design decisions to someone non-technical.”

STAR framework:

• Situation: Who was the audience? What was their background? Why did they need to understand?
• Task: You needed to communicate clearly without jargon.
• Action: How did you explain it? Did you use analogies, examples, prototypes, or user data? Did you adjust your language?
• Result: Did they understand? Did it change their perspective?

Tip: Show that you can translate design thinking into business impact and user value, not just talk about aesthetics.

”Tell me about a time you had to deliver a project with limited resources (time, budget, or tools).”

STAR framework:

• Situation: What was the constraint? How much time/budget/resources were you missing?
• Task: You needed to deliver something valuable anyway.
• Action: What did you cut? What did you prioritize? What creative solutions did you find? Did you communicate with stakeholders about tradeoffs?
• Result: What did you ship? What was the impact?

Tip: Show resourcefulness and pragmatism. Avoid the impression that you make excuses.

Technical Interview Questions for UI Designers

These questions test your hands-on knowledge, tool proficiency, and understanding of how UI design connects to front-end development. Rather than memorizing answers, learn the frameworks and principles behind them.

”Explain the difference between UI and UX, and how they work together.”

Framework:

UI is the interface—the buttons, typography, colors, layout, and interactive elements that users see and interact with. UX is the overall user experience—how easy the product is to use, whether it solves problems, and how it makes users feel.

In practice: A website could have beautiful UI (great design, good aesthetics) but poor UX (hard to navigate, slow to load, confusing information hierarchy). Or it could have plain UI but excellent UX (simple, fast, intuitive).

As a UI Designer, your job is to make sure the visual and interactive design supports the user experience. You work closely with UX Designers and researchers to understand user needs, then you bring that to life visually and interactively.

What they’re evaluating: Do you understand that you’re not just making things pretty? Can you articulate the relationship between your visual choices and how users actually interact with the product?

”Walk me through how you’d approach designing a component that needs to work across web, iOS, and Android.”

Framework:

Start by understanding the constraints and affordances of each platform:

• Web: You have more screen real estate. You can use hover states. Keyboard navigation is important.
• iOS: Touch-first interaction. Safe areas and notches matter. iOS has its own design system (Human Interface Guidelines) and interaction patterns.
• Android: Material Design is the standard. Different screen sizes and manufacturers. Back button behavior is different.

Your approach: Instead of designing once and resizing, design for each platform’s paradigms. A navigation component might be a sidebar menu on web, a tab bar on iOS, and navigation drawer on Android.

However, maintain consistency in core functionality and visual identity. Users shouldn’t feel like they’re using three different products.

Document the design system (spacing, typography, colors) so it’s consistent across platforms while respecting platform-specific patterns.

What they’re evaluating: Do you understand platform differences? Can you balance consistency with platform appropriateness?

”How would you hand off a design to a developer, and what information do you think is most important to include?”

Framework:

A good design handoff includes:

1. Visual specifications: Colors (in hex or RGB), typography (font family, weight, size, line height), spacing (margins and padding), border radius, shadows.
2. Component documentation: What variations exist? When should each one be used? What are the states (default, hover, active, disabled)?
3. Interactions: How do elements behave when clicked? What’s the timing? Are there transitions or animations?
4. Content specifications: What’s a label maximum character length? Can text wrap or truncate?
5. Edge cases: What happens with very long text? Empty states? Error states? Loading states?

Tools for this: Figma specs are good. Storybooks are even better for component-heavy projects. Clear naming conventions in your design file matter a lot.

What they’re evaluating: Do you think about implementation? Can you be detail-oriented without being precious about pixels? Do you understand the developer’s perspective?

”Explain responsive design and breakpoints. How would you approach a design system that needs to work at multiple breakpoints?”

Framework:

Responsive design means the layout and interactions adapt to different screen sizes.

Breakpoints are typically:

• Mobile: < 768px
• Tablet: 768px – 1024px
• Desktop: > 1024px

But these are guidelines, not rules. Your breakpoints should be based on when your content actually breaks.

For a design system: Define core components once, then show how they adapt at different breakpoints. A button stays a button, but on mobile it might be full-width, while on desktop it’s sized to content. A grid might be 1 column on mobile, 2 on tablet, 4 on desktop.

Document these variations. Show examples. Make it easy for developers to understand what the layout should be at each breakpoint.

What they’re evaluating: Do you understand that responsive isn’t just about scaling? Can you think systematically about design at different sizes?

”What’s a micro-interaction, and why would you use one in your design?”

Framework:

Micro-interactions are small, subtle animations or interactive moments that provide feedback or guide the user. Examples:

• A button that scales slightly when you hover over it
• A loading spinner that communicates something is happening
• A success checkmark animation when a form submits
• A modal that fades in instead of appearing instantly
• A notification that slides in from the top

Why you’d use them:

• Feedback: Users need to know their action registered. An interaction might be more effective than a static success message.
• Guidance: A subtle animation can draw attention to important information.
• Delight: Thoughtful motion makes interfaces feel more polished and human.

But use restraint. Over-animate and the interface feels slow and gimmicky. Micro-interactions should enhance usability, not distract from it.

What they’re evaluating: Do you understand that motion serves a purpose? Can you talk about interaction design beyond static layouts?

”How would you approach designing for accessibility, and what tools would you use?”

Framework:

Accessibility means designing for people with disabilities—visual, hearing, motor, cognitive. Key principles:

• Color contrast: Text needs sufficient contrast. Don’t rely on color alone to communicate information.
• Keyboard navigation: Everything clickable should be reachable via keyboard. Focus states need to be visible.
• Alt text: Images need descriptive text for screen readers.
• Semantic HTML: Proper heading hierarchy, labels for form inputs, etc. This is partly dev work, but you need to understand it.
• Motion: Avoid auto-playing videos or rapid flashing that could trigger seizures.

Tools:

• WebAIM Contrast Checker: Check color contrast.
• Axe: Automated accessibility testing.
• WAVE: Visual accessibility feedback.
• Screen readers: Test with NVDA or JAWS to experience your design as a blind user would.
• Keyboard-only navigation: Navigate through your prototype using only the keyboard.

What they’re evaluating: Do you see accessibility as integral, not optional? Do you have hands-on experience testing?

”Tell me about your experience with design tokens. How would you structure them?”

Framework:

Design tokens are the smallest units of a design system—they represent values like colors, spacing, typography, and shadows in a format that can be shared across design and development.

Example structure:

colors:
  primary:
    500: #0055CC
    600: #0044AA
  semantic:
    error: colors.primary.600
    success: #00AA00

spacing:
  xs: 4px
  sm: 8px
  md: 16px
  lg: 24px

typography:
  heading-1:
    font-family: Inter
    font-size: 32px
    font-weight: 700
    line-height: 1.2

Benefits:

• Consistency: Tokens ensure every designer and developer uses the same values.
• Scalability: Change a token once, and it updates everywhere.
• Handoff: Export tokens in a format developers can use (CSS variables, JSON, etc.).

What they’re evaluating: Can you think systemat