Top 10 UI/UX designer interview questions

Describe a process, then prove it with a real project.

"I start by understanding the problem and the users: I talk to stakeholders about goals and constraints, review analytics and do a few user interviews. I synthesise findings with affinity mapping into key insights and a clear problem statement. Then I map the user flow, explore several low-fidelity solutions, and pick one based on user needs, business goals and feasibility, usually with the PM and a developer. I build a prototype in Figma, test it with 5 users, iterate, and finish with high-fidelity designs using our design system, including all states and edge cases. After launch, I check metrics and feedback."

Then: "For example, on my college placement portal project…" Keep it flexible: say you adapt the process to the time and risk involved.

UX design is about the whole experience of achieving a goal: understanding users, structuring information, designing flows and making the product useful and easy. It answers "does this solve the right problem in the simplest way?"

UI design is the interface layer: visual hierarchy, layout, typography, colour, components, states and micro-interactions. It answers "is this clear, consistent and pleasant to use?"

Analogy: UX is the floor plan of a house (rooms, flow between them); UI is the finishes, fittings and signs. A beautiful UI can't save a confusing flow, and a great flow needs a clear UI to work. Most product designer roles expect both.

• Guerrilla testing: five quick sessions with people who match the audience (classmates, friends of friends, people in a café), 10–15 minutes each.
• Existing data: analytics, support tickets, app store reviews, sales and support teams' notes.
• Competitive and heuristic reviews to spot conventions and obvious issues.
• Short surveys for specific questions.
• Remote unmoderated tests with a prototype.

Prioritise the riskiest assumptions, be honest about the limits of small samples, and plan follow-up research. Showing resourcefulness is the point of this question.

Treat feedback as information about the problem, not about you.

1. Listen fully and ask clarifying questions to find the underlying concern ("What worries you about the bottom navigation?").
2. Separate opinions from evidence; bring the conversation back to user needs and goals.
3. Where you disagree, explain your reasoning with research, data or principles, and propose a way to settle it (a quick usability test or an A/B test).
4. Acknowledge good points and iterate.

Give a short real example where feedback improved your design. Interviewers want to see that you're open, not defensive, and that you can still defend user-centred decisions.

Balance three lenses: user value (how much it solves a real, frequent pain), business value (goals and metrics) and effort/feasibility (with engineering).

Tools: impact-vs-effort matrix, RICE scoring (Reach, Impact, Confidence, Effort), MoSCoW (Must, Should, Could, Won't), and the user journey (fix the biggest drop-off first). Design the MVP that tests the core value, then iterate. Mention that you involve PMs and developers early so priorities are shared.

A design system is a single source of truth for building products consistently: foundations (colour, typography, spacing, elevation and motion tokens), a component library (buttons, inputs, cards, modals with variants and states), patterns (forms, empty states, error handling), and guidelines for usage, tone and accessibility. It exists both in Figma and in code.

Benefits: consistency across screens and teams, faster design and development, accessibility built in once, easier onboarding, and less time debating basics. Costs: maintenance and governance; it must evolve with the product. Mention examples (Material, Carbon, Polaris) and any components you've built with variants and Auto Layout.

• Contrast: at least 4.5:1 for body text, 3:1 for large text and UI elements.
• Not colour alone: pair colour with icons, text or patterns for errors and status.
• Touch targets: at least 44–48 px with spacing.
• Text: readable sizes, support for dynamic type and zoom, sensible line length.
• Focus and keyboard: visible focus states, logical tab order, no keyboard traps.
• Screen readers: meaningful labels for icons and images, a proper heading structure, form labels and descriptive error messages.
• Motion: respect reduced-motion settings; avoid flashing content.
• Language: plain, clear wording.

Test with tools (contrast checkers, Stark, screen readers like TalkBack and VoiceOver) and, ideally, with users with disabilities. Accessible design usually improves usability for everyone.

Pick metrics tied to the design goal:

• Behavioural: task success rate, time on task, error rate, conversion (e.g. job view → application), drop-off at each funnel step, feature adoption, retention.
• Attitudinal: SUS score, CSAT, NPS, qualitative feedback.
• Operational: fewer support tickets about a feature.

Frameworks: Google's HEART (Happiness, Engagement, Adoption, Retention, Task success) with Goals → Signals → Metrics. Set a baseline before the change, define success up front, and watch guardrail metrics so improving one thing doesn't break another.

Pick one project and tell it as a story, using your case-study structure:

1. Context: the product, users, your role and the team.
2. Problem: what was wrong and how you knew (data, research).
3. Process: key research insights, options you explored, why you chose one, how you collaborated.
4. Challenges: a constraint or disagreement and how you handled it.
5. Outcome: measurable results or test findings, and what you learned.

Show your thinking, not just final screens. Prepare to go deep on any decision: "Why bottom tabs? Why this colour for the error state? What did testing change?"

1. Clarify: Who are the users (patients, elderly people, parents booking for children; doctors and clinics)? What platform? What's the business goal (bookings, reducing no-shows)? Any constraints (time, existing system)?
2. State assumptions and pick a focus: "I'll design the patient booking flow on mobile for a city clinic network."
3. Map the journey: find a doctor (search or specialty) → compare (availability, fees, ratings, distance, language) → pick a slot → confirm details → pay or pay at clinic → reminders → reschedule or cancel.
4. Identify pain points: uncertainty about availability, long forms, no-shows, booking for family members.
5. Sketch the key screens: doctor list with next available slot, a slot picker, a one-screen confirmation, reminders with easy reschedule.
6. Detail one screen with hierarchy, states (no slots available, payment failure) and accessibility.
7. Measure and test: booking completion rate, time to book, no-show rate; test with 5 users including older adults.

Thinking out loud and making trade-offs explicit matters more than polish.