UI/UX design interviews explore your design process, how you research and test with users, visual and interaction design skills, and how you work with product managers and developers. Expect to talk through real projects and decisions.
Fundamentals, definitions and simple scenarios. Good for freshers and warm-ups.
UI design is the visual and interactive surface of a product: layout, typography, colour, buttons and states. UX design is the whole experience of using it: understanding users through research, defining flows and information architecture, and making sure the product is useful and easy to use. Good UI can't fix poor UX, and a strong UX needs a clear UI to work.
A wireframe is a low-fidelity layout showing structure and content placement without visual styling. A mockup is a high-fidelity static design showing how the product will actually look. A prototype is interactive, letting people click through flows, and is used to test ideas with users and communicate behaviour to developers.
Visual hierarchy is arranging elements so people notice the most important things first. It is controlled with size, weight, colour and contrast, spacing, position and grouping. For example, a page title is largest, the main call-to-action has the strongest colour, and secondary actions are quieter, so users can scan the page and know what to do.
A design system is a shared library of reusable components, design tokens (colours, typography, spacing) and usage guidelines, kept in sync between design files and code. It makes products consistent, speeds up design and development, and makes accessibility easier to get right everywhere. Well-known examples are Google's Material Design and Atlassian's design system.
Applied problems, trade-offs and questions about your own projects.
I start by understanding the problem and the business goal, then research users through interviews, analytics or competitor reviews. I define the problem clearly, often with personas and journey maps, and explore solutions through sketches and user flows. I build a prototype, test it with real users, iterate on what I learn, then hand off to developers and measure the results after launch.
I set clear goals and realistic tasks, and recruit about five representative users per round, which reveals most major issues. I ask participants to think aloud, observe without leading them, and note where they hesitate, make errors or succeed. I measure task success, time and errors, then group the findings, rank them by severity and turn them into design changes.
I make sure text meets WCAG contrast ratios (4.5:1 for normal text), never use colour alone to show meaning, use readable font sizes and make touch targets large enough, around 44 to 48 pixels. I design visible focus states and a logical reading order, and specify labels, alt text and error messages. I check designs with contrast tools and review the built product with keyboard and screen reader testing.
I listen to understand the concern behind the feedback, then bring evidence: research findings, recordings or data, framed around the shared business goal. Often there is a solution that addresses both. When we still disagree, I suggest testing both options with users or through an A/B test, so the decision is based on evidence rather than opinion, and I document the outcome.
System design, deep internals, leadership and tough follow-ups.
I agree on success metrics before launch, linked to the goal: task success rate, conversion, time on task, retention, error rates or fewer support tickets. Frameworks such as Google's HEART (happiness, engagement, adoption, retention, task success) help, and SUS scores measure perceived usability. I combine these numbers with qualitative feedback to understand why they moved.
I involve developers early to check feasibility, design with components and tokens that match the codebase, and use Figma's Dev Mode for specs. I document every state (hover, focus, error, empty, loading) and responsive behaviour, stay available for questions during the build, and review the implementation before release so small gaps are caught.
I would first look at funnel analytics to find the step where people leave, watch session recordings and talk to users. Typical causes are forced account creation, surprise shipping costs, long forms, few payment options and low trust. Fixes include guest checkout, showing total cost early, fewer fields with autofill, UPI and wallet options, and trust signals. I would A/B test the changes and track completion rate.
I usually design mobile-first, which forces me to prioritise content, then adapt to larger screens with fluid grids and flexible components. Breakpoints are set where the content needs them, not by specific devices. I decide how navigation, tables and images change on each size, and test on real devices because touch, screen density and real content often reveal problems mockups hide.