Q1: Walk me through your design process

Why they ask: This is the single most common UI/UX interview question. Interviewers want to see a structured framework, not a vague answer. The Double Diamond model is the most recognized approach.

How to answer: Reference the Double Diamond framework — Discover, Define, Develop, Deliver. Discover: understand the problem through research (user interviews, analytics, competitor analysis). Define: synthesize findings into a clear problem statement and user personas. Develop: ideate solutions through sketching, wireframing, and prototyping. Deliver: test with users, iterate based on feedback, and hand off to development.

Back this up with a real example. If you redesigned an onboarding flow, walk through how you discovered the drop-off problem (analytics showed 60% abandonment at step 3), defined the core issue (too many form fields upfront), developed solutions (progressive disclosure, social login), and delivered the final design (A/B tested, 35% improvement in completion rate).

What separates good from great: Great candidates mention that the process is not always linear — sometimes you loop back from Develop to Discover when testing reveals new insights. Show that you adapt the process to project constraints rather than following it rigidly.

Q2: How do you handle a project with no user research budget?

Why they ask: Most companies, especially startups, do not have dedicated research budgets. Interviewers want to see resourcefulness — can you still make informed design decisions without a formal research team?

How to answer: Guerrilla testing is your first tool — grab 5 people from a coffee shop or hallway and run quick usability tests on paper prototypes. It costs nothing and catches 85% of major usability issues. Analytics data from tools like Google Analytics, Hotjar, or Mixpanel reveals what users actually do (heatmaps, session recordings, funnel drop-offs). Competitor analysis shows what patterns users already understand. Stakeholder interviews with customer support, sales, and product teams surface real user pain points without talking to a single user directly.

What separates good from great: Mention that no research budget is not the same as no research. Even reading app store reviews, support tickets, and social media complaints counts as secondary research. The worst answer is skipping research entirely and designing based on assumptions.

Q3: What is the difference between UX and UI?

Why they ask: This sounds basic, but many candidates give vague or incorrect answers. Interviewers use this to gauge whether you understand the full scope of the discipline or just the visual layer.

How to answer: UX (User Experience) is the entire journey a user takes to accomplish a goal — it includes research, information architecture, interaction design, usability, and the emotional response to the product. UI (User Interface) is the visual and interactive layer — typography, color, spacing, icons, buttons, animations, and how the interface looks and responds to input. They overlap significantly but are not the same.

Use a concrete example: A checkout flow with excellent UX has minimal steps, clear progress indicators, and smart defaults. Excellent UI means the buttons are visually distinct, the form fields have proper labels and error states, and the typography creates a clear visual hierarchy. You can have great UI with terrible UX (a beautiful form that asks for 20 fields) or great UX with mediocre UI (a simple flow that looks outdated).

Common mistake to avoid: Do not say UI is "how it looks" and UX is "how it works." That oversimplification misses the point. UX includes strategy, research, and architecture — it is not just about functionality. UI includes motion design, micro-interactions, and responsive behavior — it is not just about colors and fonts. Show that you understand the full depth of both disciplines.

Q1: What user research methods have you used?

Why they ask: Interviewers want to see breadth of knowledge and the judgment to pick the right method for the right situation. Listing methods is not enough — you need to explain when and why you would use each one.

How to answer: User interviews work best for understanding motivations, pain points, and mental models early in a project — typically 5-8 participants reveal most patterns. Surveys scale when you need quantitative validation across a larger audience (100+ responses). Usability testing catches interaction problems — run moderated tests for deep insights or unmoderated tests for speed. A/B testing validates design decisions with real user behavior at scale. Card sorting helps define information architecture when you are organizing navigation or content structure. Heatmaps and session recordings from tools like Hotjar reveal where users click, scroll, and get stuck.

What separates good from great: Explain the trade-offs. Interviews give depth but not scale. Surveys give scale but not depth. A/B tests give behavioral data but not the why behind it. The best researchers triangulate — combine qualitative and quantitative methods to build a complete picture.

Q2: How do you create user personas?

Why they ask: Personas are one of the most misused tools in UX. Interviewers want to know if you create useful, data-driven personas or decorative ones with stock photos and made-up quotes.

How to answer: Data-driven personas are built from actual research — interview transcripts, survey data, analytics segments, and customer support logs. You identify behavioral patterns and group users by goals, frustrations, and usage patterns — not demographics. A useful persona includes the user's primary goal, key frustrations, decision-making factors, and the context in which they use the product. An assumption-based persona (created without research) is a starting hypothesis that must be validated — it is better than nothing but should never be treated as truth.

What makes a persona useless: Stock photo, fictional name, demographic details that do not affect design decisions (hobbies, favorite coffee). What makes a persona useful: specific behavioral patterns, real quotes from research, scenarios that directly inform feature prioritization and design decisions.

Q3: How do you measure the success of a design?

Why they ask: This question separates designers who ship and forget from designers who measure impact. If you cannot define success metrics before designing, you cannot prove your design worked.

How to answer: Task completion rate measures whether users can accomplish their goal — if only 40% of users complete checkout, the design has a problem. Time on task measures efficiency — a redesigned settings page should take less time to find the right option. Error rate tracks how often users make mistakes (wrong clicks, form errors, back-button usage). The System Usability Scale (SUS) is a standardized 10-question survey that gives a usability score out of 100 — anything above 68 is above average. Net Promoter Score (NPS) measures user satisfaction and loyalty. Conversion rate ties design directly to business outcomes.

What separates good from great: Define success metrics before you start designing, not after. Mention that you align metrics with business goals — a redesign that improves usability but drops conversion is not a success. Show that you track both quantitative metrics (completion rate, time on task) and qualitative feedback (user satisfaction, support ticket volume).

Q1: Explain your approach to design systems

Why they ask: Design systems are how companies scale design consistency across products and teams. If you have worked on or contributed to a design system, this is where you demonstrate systems thinking.

How to answer: A design system starts with design tokens — the foundational values for color, typography, spacing, and elevation that ensure consistency across every component. From tokens, you build a component library in Figma with variants for every state (default, hover, active, disabled, error, loading). Each component needs clear documentation: when to use it, when not to use it, accessibility requirements, and code implementation notes. The system should include patterns (how components combine for common use cases like forms, navigation, and data tables) and guidelines (voice and tone, iconography rules, illustration style).

What separates good from great: Mention that a design system is a product, not a project — it needs governance, versioning, and adoption metrics. Talk about how you handle component requests, breaking changes, and cross-team alignment. Consistency at scale is the goal, not pixel-perfect control.

Q2: What accessibility considerations do you follow?

Why they ask: Accessibility is no longer optional — it is a legal requirement in many markets and a core design skill. Interviewers want to see that you build accessible designs by default, not as an afterthought.

How to answer: Start with WCAG guidelines as the foundation. Color contrast ratios must meet minimum thresholds — normal text needs at least 4.5:1 contrast against its background, large text needs 3:1. Never use color alone to convey information (add icons, patterns, or text labels alongside color indicators). Keyboard navigation must work for every interactive element — users should be able to tab through forms, activate buttons with Enter/Space, and navigate menus with arrow keys. Screen reader support requires semantic HTML, proper heading hierarchy, descriptive alt text for images, and ARIA labels for custom components. Touch targets on mobile should be at least 44x44 pixels.

What separates good from great: Mention that you test with actual assistive technologies — not just automated checkers. Talk about designing for cognitive accessibility too: clear language, consistent navigation, error prevention, and undo functionality. Accessibility benefits everyone, not just users with disabilities.

Q3: How do you design for mobile vs desktop?

Why they ask: Multi-device design is a core skill. Interviewers want to see that you understand the constraints and opportunities of each platform — not just that you can resize a layout.

How to answer: Mobile-first design means starting with the smallest screen and progressively enhancing for larger ones — this forces you to prioritize content and features ruthlessly. Responsive design uses fluid grids and breakpoints to adapt a single layout across screen sizes. Adaptive design serves different layouts for specific screen sizes — more work but more control. Thumb zones matter on mobile: primary actions should be in the bottom third of the screen where thumbs naturally rest. Progressive disclosure is critical on mobile — show only what users need at each step and reveal complexity on demand. Navigation patterns differ: bottom navigation bars on mobile vs sidebar or top navigation on desktop.

What separates good from great: Discuss context differences — mobile users are often multitasking, on slower connections, and in variable lighting conditions. Desktop users typically have more focused attention and larger interaction areas. The same feature might need fundamentally different interaction patterns on each platform, not just a different layout.

Q1: Walk me through your favorite project

Why they ask: This is your chance to demonstrate end-to-end design thinking. Interviewers evaluate your ability to frame a problem, describe your process, and quantify results — not just show pretty screens.

How to answer: Use the structure: Problem → Research → Ideation → Solution → Results. Start with the business problem and user pain point (not the visual solution). Describe what research you conducted and what you learned. Walk through your ideation process — show sketches, wireframes, and how the design evolved. Present the final solution and explain key design decisions. End with measurable results: conversion increased by 25%, support tickets dropped by 40%, task completion time reduced from 3 minutes to 45 seconds.

What separates good from great: Show the messy middle — the ideas that did not work, the user feedback that surprised you, the constraints that forced creative solutions. Interviewers distrust portfolios that show a clean, linear path from problem to perfect solution. Real design is iterative and messy.

Q2: How do you handle design critique?

Why they ask: Design is collaborative. If you cannot receive feedback without getting defensive, you will be difficult to work with. This question tests emotional maturity as much as design skill.

How to answer: Separate your ego from your work — the critique is about the design, not about you. When receiving feedback, ask clarifying questions before reacting: "Can you help me understand what specific problem you see?" or "What user scenario are you thinking about?" This turns vague opinions into actionable feedback. Evaluate feedback against your research and design principles — not all feedback is equal. Stakeholder preferences are not the same as user needs. Iterate based on feedback that aligns with user goals and business objectives.

What separates good from great: Give a specific example of feedback that changed your design for the better. Show that you actively seek critique rather than avoid it — mention design review rituals, peer feedback sessions, or how you structured critique in your team.

Q3: Tell me about a design that failed

Why they ask: Every designer has failures. Interviewers want to see humility, self-awareness, and the ability to learn from mistakes. Claiming you have never had a design fail is a red flag.

How to answer: Pick a real example. Describe what you designed, what the expected outcome was, and what actually happened. Be honest about what went wrong — maybe you skipped user testing due to time pressure, or you designed for an edge case that turned out to be the primary use case, or you over-designed a feature that users found confusing. Explain what you learned and how it changed your approach going forward.

What separates good from great: Show that the failure led to a concrete process change — not just a lesson learned. If a design failed because you skipped research, explain how you now build research into every project timeline regardless of deadlines. If it failed because of poor developer handoff, explain the documentation process you created to prevent it.

Q1: What design tools do you use and why?

Why they ask: Interviewers want to see that you choose tools intentionally based on project needs — not just because everyone else uses them. They also want to gauge your actual proficiency level.

How to answer: Figma is the industry standard for UI design and collaboration — real-time multiplayer editing, component libraries, auto-layout, and dev mode make it the default choice for most teams. Sketch is still used in some legacy workflows, particularly at companies that invested heavily in Sketch plugin ecosystems. Adobe XD exists but has lost significant market share. For prototyping beyond Figma, tools like ProtoPie handle complex micro-interactions and sensor-based prototypes. For user research, Maze integrates with Figma for unmoderated usability testing. Whimsical or FigJam work well for early-stage ideation, user flows, and workshop facilitation.

What separates good from great: Be honest about your proficiency levels. Saying you are an expert in every tool is not credible. Mention your primary tool and why, acknowledge tools you are learning, and explain how you evaluate new tools. The tool matters less than the output and the collaboration it enables.

Q2: How do you hand off designs to developers?

Why they ask: The design-to-development handoff is where most design quality is lost. Interviewers want to see that you take responsibility for implementation quality, not just the Figma file.

How to answer: Start with design specs — every component should have documented spacing, typography, color tokens, and interaction states (hover, active, disabled, error, loading, empty). Figma Dev Mode gives developers inspect access to measurements, CSS properties, and assets without needing a separate spec document. Component documentation should include usage guidelines, edge cases (what happens with long text, empty states, error states), and responsive behavior at each breakpoint. Beyond the file, communication matters — walk developers through the design before they start building, discuss technical constraints early, and review implementations together.

What separates good from great: Mention that handoff is not a one-time event — it is an ongoing conversation. Talk about how you handle implementation questions, review pull requests for visual accuracy, and iterate when technical constraints require design adjustments. The best designers sit with developers during implementation.

Q3: How do you work with product managers and engineers?

Why they ask: Design does not happen in isolation. Interviewers want to see that you can navigate cross-functional relationships, handle conflicting priorities, and contribute to product strategy — not just take orders and make mockups.

How to answer: With product managers, build shared understanding early — participate in discovery, align on problem statements before jumping to solutions, and use design sprints to rapidly explore and validate ideas together. With engineers, involve them in the design process from the start — their technical knowledge prevents you from designing things that are impossible or unnecessarily expensive to build. Trade-off discussions are inevitable: when a PM wants a feature that compromises usability, or an engineer flags that an animation will hurt performance, you need to facilitate a conversation that balances user needs, business goals, and technical feasibility.

What separates good from great: Give a specific example of a trade-off you navigated. Maybe you simplified a complex interaction because the engineering effort was disproportionate to the user benefit, or you pushed back on a PM request because user research showed it would confuse users. Show that you are a partner in product decisions, not just a service provider.