UI/UX Designer interview questions (India, 2026): what to ask and what to listen for

12 interview questions for a UI/UX Designer role, grouped by what each round should establish, each with what a strong answer contains, plus a five-point scorecard so every interviewer rates the same things.

Last updated 3 September 2026. Competitor pricing and plan limits are re-verified against each vendor’s own pages.

Interviewing a UI/UX Designer well means asking about work the candidate has actually done, listening for specifics, and scoring every candidate on the same five criteria. The questions below are grouped by what they establish; each one comes with what a good answer contains, which is the part most question lists leave out.

A UI/UX Designer owns how the product looks and works for users — research, flows, wireframes, high-fidelity screens in Figma, a design system and the handoff to engineers — designing first for the phone in an Indian user's hand rather than the designer's monitor.

Use the screening questions on the job description page to filter before anyone reaches an interview, and the scorecard at the end so a panel can compare candidates rather than impressions.

Portfolio and reasoning

Walk me through one product in your portfolio from problem to shipped screens. What did you learn from users, what did you change because of it, and what would you redo?: A strong answer: A real process with research, decisions grounded in observation, and honest hindsight. Designers who only show final screens cannot answer this.
Show me the empty, loading and error states for one of those screens.: A strong answer: Designed them, not just the happy path. Their absence is the most common gap between a portfolio and shipped work.
How did that product perform on a low-end Android phone, and what did you design differently because of it?: A strong answer: Awareness of real devices and connectivity — touch targets, type size, image weight, offline states.
Tell me about a design decision an engineer pushed back on for technical reasons. What happened?: A strong answer: Understood the constraint, found an alternative that kept the intent, and did not either cave or dig in.

Design craft

Here is a flow from our product [show it]. What would you change, and why?: A strong answer: Observes before judging, identifies real usability issues with reasons, and prioritises — not a list of visual preferences.
Design a form for [a small task in your product] on paper: fields, order, validation, error handling, and what happens on a slow connection.: A strong answer: Thinks in states and sequences; minimises fields; handles failure kindly; considers the device.
How would you set up a design system for a three-person product team? What goes in first, and what waits?: A strong answer: Proportion — tokens, a few core components, spacing and type — and the discipline to grow it from real screens rather than build it all upfront.
What accessibility issues do you check for on every screen, and how?: A strong answer: Contrast, touch targets, focus order, labels, text scaling — with tools and a habit, not just awareness.

Working in a small team

How do you run a usability session with five users in a week, and what do you do with the results?: A strong answer: A lightweight, repeatable method — tasks, observation, notes, a decision list — realistic for an SME.
The PM wants a screen by Friday and you think the flow is wrong. What do you do?: A strong answer: Raises the concern with evidence, proposes the smallest fix that can ship by Friday, and plans the fuller change.
How do you hand off to engineers so that what ships matches the design?: A strong answer: Specs with states and spacing, a component library they can use, and review of the implementation — collaboration rather than throwing files over a wall.
In a small company you will also make a landing page and app-store screenshots. How do you feel about that?: A strong answer: Realistic acceptance of breadth and some evidence of having done it.

Scorecard for UI/UX Designer interviews

Score each candidate on these five criteria, one to four, straight after the interview and before talking to the other interviewers. Written scores taken independently are what make a panel decision defensible; a discussion first produces one opinion with several signatures.

End-to-end reasoning: research to shipped screens with grounded decisions.
Completeness: empty, loading, error and edge states designed.
Device and accessibility reality: designs for low-end phones and checks accessibility habitually.
Craft and proportion: usable flows, forms in states, a design system sized to the team.
Collaboration: engineers, PM and deadlines handled without losing intent.

Screen before you interview

Most UI/UX Designer interviews that go badly were avoidable at the application stage. The job description template for this role carries five screening questions that settle the deal-breakers — notice period, location, the one or two hard requirements — before anyone books a slot.

Can you share a portfolio showing at least one shipped product you designed end to end, with your reasoning? — knockout
How many years have you designed shipped digital products in Figma or an equivalent tool? — knockout
Are you able to work [from our City office X days a week / remote with overlap hours]? — knockout
What is your current notice period, in days? — for context

Questions, answered straight

What is the best UI/UX Designer interview question?

Ask them to walk through one portfolio product from problem to shipped screens — what they learned from users, what they changed, what they would redo — and then ask to see the empty, loading and error states. Process and completeness are the two things a portfolio of final screens hides.

How do I assess mobile-first design for Indian users?

Ask how a product they designed performed on a low-end Android phone and what they changed because of it. Designers who have watched real users on real devices answer with touch targets, type size, image weight and offline states.

How do I assess collaboration with engineers?

Ask about a design decision an engineer pushed back on for technical reasons and what happened. The answer you want understood the constraint and found an alternative that kept the intent — neither caving nor digging in.