UI/UX Designer interview questions and answers

Start with what you need to learn, and recruit five to eight people who match the target users. Write a short guide of open questions about their past behaviour: "Tell me about the last time you booked a train ticket" teaches far more than "Would you use an app that...?", because people are poor at predicting what they'll do. In the session, build rapport, ask one question at a time, follow up with "Why?" and "Can you show me?", and stay quiet so they keep talking. Avoid leading questions such as "Don't you find this confusing?".

Record with permission, take notes, and write down the key observations straight after. Interviewers want to hear that you listen more than you talk.

A persona is a short profile of a typical user, built from research, that sums up their goals, needs, frustrations, behaviour and context: for example, a shop owner in a small town who uses UPI every day but avoids long forms. It keeps the team designing for real people rather than for themselves, and helps settle debates: "Would she understand this screen?"

A persona becomes useless when it's invented instead of based on research, when it's filled with irrelevant details like a favourite food, or when it's made once and never used in decisions. Goals and behaviour matter more than demographics. Some teams prefer jobs-to-be-done statements for exactly this reason.

A journey map shows one user's experience of reaching a goal over time, stage by stage: what they do, think and feel at each stage, the touchpoints they use, and the pain points and opportunities. It's built from research, not guesses.

For booking a doctor: noticing symptoms and searching (worried, unsure which specialist); comparing doctors (reviews, fees, distance; frustrated if fees are hidden); booking (choosing a slot and paying; anxious whether it's confirmed); waiting (wants a reminder and directions); the visit (a long wait despite booking); and follow-up (prescription and reports). The low points become design opportunities, such as a clear WhatsApp confirmation and a live queue status.

First get the raw observations out: quotes, actions and pain points on sticky notes or in a tool like FigJam or Miro, one observation per note, tagged by participant. Then do affinity mapping: group similar notes, name each group, and look for patterns across several participants rather than one loud quote.

Turn patterns into insights that explain why, not just what: not "users don't use filters" but "users don't trust filters because the results don't visibly change, so they scroll instead". Prioritise by how many users it affects and how badly, and frame the top ones as "How might we..." questions. Share a short summary with quotes and clips; stakeholders act on what they can see and hear.

Visual hierarchy is the order in which people notice things on a screen, so the most important element is seen first and the next step is obvious. You create it with size (bigger catches the eye first), weight and colour (a bold heading, one strong primary button), contrast, spacing (whitespace gives an element importance and groups related items), and position, since people usually scan from the top left in left-to-right languages.

On a payment screen, for example, the amount and the Pay button should stand out, while secondary actions like "Change method" are quieter. A quick check is the squint test: blur your eyes and see what stands out. If everything is bold, nothing is.

Use one typeface, two at most, chosen for readability on screens, from a family that supports the scripts you need, such as Devanagari or Tamil if the app is multilingual. Set a type scale, a small set of sizes for headings, body text and captions, and show hierarchy with size and weight rather than many fonts.

For readability: body text of about 16px on the web, line height around 1.4 to 1.6 for body text, lines of roughly 45 to 75 characters, and enough contrast against the background. Left-aligned paragraphs are easier to read than justified or centred ones. Test with real content, long names and translations, not lorem ipsum.

Start with the brand's primary colour, add one or two accents, a range of neutrals for text, backgrounds and borders, and semantic colours for success, warning and error. Create tints and shades of each for backgrounds, hover states and borders, and name them as tokens by role, such as primary, surface and error, rather than by appearance.

Then check contrast: WCAG level AA asks for at least 4.5:1 for normal text, and 3:1 for large text and for essential interface parts like field borders and icons. Never use colour alone to carry meaning, since roughly one in twelve men has some colour vision deficiency; add an icon or a word. Check dark mode too, if you support it.

An 8-point system means spacing and most sizes are multiples of 8 (8, 16, 24, 32), with 4 for fine adjustments. It keeps spacing consistent across screens and designers, speeds up decisions, and matches the spacing tokens developers use, so the built product matches the design. Related items get less space between them than unrelated ones, which groups content without extra lines or boxes.

For layouts I use a column grid, typically 4 columns on mobile, 8 on tablet and 12 on desktop, with set gutters and margins, so content aligns and adapts across breakpoints. The grid is a guide, not a cage: break it on purpose for emphasis. Defining spacing as variables in Figma keeps the whole team consistent.

A wireframe is a low-fidelity layout of a screen: boxes, placeholder text and basic structure, without colour or real images. It's fast to make and change, and keeps the discussion on content and flow rather than looks. A mockup is a high-fidelity static design showing exactly how the screen will look, with real typography, colours and images. A prototype is interactive: screens linked so people can tap through a flow, and it can be low fidelity, built from wireframes, or high fidelity.

Use wireframes early to explore ideas cheaply, prototypes to test flows with users before development, and mockups for final visual sign-off and developer handoff.

The happy path: enter the mobile number, tap Get OTP, see a screen that shows the number with an option to edit it, enter the code (often read automatically from the SMS on Android), and land on the home screen. New users then go to a short profile step.

The edge cases matter more: an invalid number, a wrong OTP with a clear message and the attempts left, an expired OTP, an SMS that never arrives (a resend button with a visible countdown, and perhaps a WhatsApp or voice-call option), too many attempts, no internet, and a user who has changed their number. Each needs its own screen state or message, so draw them in the flow, not only the success path.

Microinteractions are small, single-purpose moments of feedback, made of a trigger, rules for what happens, the feedback itself, and sometimes a loop. Examples: a button that shows a spinner and then a tick after a payment, a heart that animates when tapped, pull-to-refresh, a toggle sliding across, a PIN field shaking gently after a wrong entry, or a counter of characters left.

Add one when it answers a user's question: did my tap work, what's happening, what changed? Keep it short, usually a few hundred milliseconds, consistent across the app, and never in the way of the task. Respect the system's reduce-motion setting, and pair animation with a change in text or state. Decoration for its own sake soon gets tiring.

It depends on what users are doing. Infinite scroll suits browsing with no particular goal, like a social feed: it's effortless and keeps people engaged. But the footer becomes unreachable, users lose their place when they come back, and finding an item again is hard. Pagination suits goal-driven tasks where people compare or return to items, like search results, order history or admin tables: they know how much there is and can return to page 3. "Load more" sits in between: continuous like scrolling, but under the user's control, with the footer still reachable.

For shopping listings, "Load more" that keeps the scroll position when users come back is often a good compromise. Test it with real users.

Auto layout makes a frame arrange its children in a row or a column with set padding and gaps, much like Flexbox in CSS. When the content changes, the frame adjusts: a button grows with its label, and a list reflows when you add an item, so you don't fix spacing by hand. It can also wrap items onto new rows.

Sizing is set per direction. Hug contents makes the frame exactly as big as its content plus padding, as for a button. Fill container stretches an element to fill the space available in its parent, as for a text field across a form. Fixed keeps a set size. Using auto layout properly makes designs responsive and maps directly to how developers build them.

A component is a reusable element: you design the main component once, and every copy, an instance, updates when the main one changes, while still allowing overrides such as the label text. Variants group related versions of a component into one set controlled by properties, so a designer picks options in the panel instead of hunting for separate components.

For a button, I'd make variants for type (primary, secondary, text), size (small, medium, large) and state (default, hover, pressed, disabled, loading), all built with auto layout. Component properties add a text property for the label, a boolean to show or hide an icon, and an instance swap to choose the icon. Colours and spacing come from variables, so a theme change updates everything.

Start from the flow you're testing, not the whole app, and make every path in it work, including going back and the errors you want to observe. Use interactions such as on tap and after delay, Smart Animate for transitions between similar screens, overlays for menus and bottom sheets, and interactive components so a toggle or checkbox works wherever it's used. Variables and conditions can make it feel real, such as a cart count that updates.

Use realistic content, like Indian names, prices in rupees and real product photos, because placeholders confuse testers. Test it on a phone at real size through the Figma mobile app. Know when to stop: if it needs heavy logic, a coded prototype may be quicker.

Involve developers before handoff, so technical limits come up early. Then make the file easy to build from: final screens on clearly named pages, separate from explorations; components and auto layout that mirror the code components; colours, type and spacing as variables or styles named like the design tokens in code; and every state designed, including empty, loading, error, long text and different screen sizes.

In Dev Mode, mark frames ready for development and add annotations for behaviour a static screen can't show, such as validation rules and animations. Walk the developers through it, then review the built screens before release and log any differences as tickets, so nothing becomes a last-minute surprise.

As an assistant for speed, not a replacement for thinking. For example: a first-pass summary of interview notes before my own synthesis, drafts of interface copy and error messages that I then edit, varied realistic content for prototypes, moodboard images or illustrations from image tools such as Midjourney or Adobe Firefly, and Figma's AI features to rename layers or draft a first layout from a prompt.

I always check and edit the output: AI summaries can invent or flatten findings, and generated layouts tend to be generic. I also never put confidential client data or unreleased designs into a tool without permission. Give a concrete example of time you saved and the part you still did yourself.

Be as specific as you would be with an illustrator: the subject (a young woman paying at a kirana shop with her phone), the style (flat vector illustration, soft gradients, friendly), the colours (the brand's indigo and green on a light background), the composition (subject on the right, empty space on the left for the headline), the aspect ratio of the screen, and what to avoid (text, logos, distorted hands). Mention the audience and the mood: trustworthy, simple, Indian context.

Then iterate: generate several, keep what works, change one thing at a time, and use reference images if the tool supports them. Finally, refine it in a design tool so it fits the brand, and check the tool's licence for commercial use.

AI personas look convincing but aren't research: they're averages of what the model has seen, so presenting them as real users misleads the client and every decision built on them. Use them only as clearly labelled assumptions to check with real users. For generated screens, check that they follow the design system, work with real content and edge cases, meet accessibility needs such as contrast and touch-target size, and aren't close copies of an existing product.

Also check rights and data: the tool's licence for commercial use, whether any client data was pasted into it, and the client's own policy on AI. Being open about where AI was used builds trust rather than losing it.

Tell it as a story in about five minutes, with a clear structure: the problem and why it mattered, your role and constraints (team, time, tools), what research showed, the ideas you explored and why you dropped some, the final design, and the outcome. For example: "Students at my college missed lab-slot sign-ups because notices were lost in WhatsApp groups. I interviewed [number] students and staff, mapped the current process, tested two flows with paper prototypes, and built a Figma prototype. In testing, the time to book fell from [x] to [y]."

Show your decisions and trade-offs, not only the final screens, and be clear about what you did and what the team did.

Don't jump to screens. Spend the first few minutes clarifying: who the users are, what's going wrong (drop-off at payment, wrong addresses, complaints about hidden charges), the business goal, and constraints such as the platform. If the interviewer won't say, state your assumptions aloud. Then map the current flow and pick the biggest pain point, explaining why.

Sketch two or three ideas, such as showing the full price breakdown earlier, saved addresses confirmed on a map, or one-tap UPI with a clear fallback, and talk through each one's trade-offs. Develop one into a rough flow with edge cases like a failed payment. Finish with how you'd measure success, such as checkout completion and support tickets.

Decide the measures before launch, tied to the problem. Behaviour measures: task success rate, completion or conversion rate, drop-off at each step, time on task, error rate, and support tickets about the feature. Attitude measures: satisfaction ratings, the System Usability Scale, and written feedback. Compare against a baseline, ideally with an A/B test that shows the new design to some users and the old one to others, so you know the change caused the difference and not, say, a festival sale.

Pair the numbers with usability sessions: data shows what changed, sessions show why. In a portfolio, even a small usability test with before and after results is far stronger than "users loved it".

Make it a short story of how you think as a designer, leading to your portfolio. For example: "I'm a [degree] graduate from [college], and I came to UX through [how: designing posters for college events and wondering why some worked better than others]. Since then I've completed [course or internship], where I [what you did: ran usability tests on a banking app and redesigned its bill-payment flow]. My favourite project is [project], where research changed my first idea completely. I'm looking for a role where I work closely with researchers and developers on products people use every day."

Keep your portfolio open and ready to share.

Give a real reason connected to people and problems, not only to liking visuals. For example: "I enjoy finding out why something is hard for people and making it easier. During my [engineering degree / previous job in customer support], I saw users struggle with [example], and I realised many of those problems were design problems. That led me to [course or projects]. I like that UX combines understanding people, logical thinking and visual craft."

If you're switching careers, show how your background helps: support staff know users' pain, and engineers understand constraints. Don't say you chose UX because it needs no coding.

Stay calm, ask questions to find the real concern, and bring the discussion back to users and goals rather than taste. For example: "I'd ask what specifically feels wrong and what they expected. 'I don't like it' often hides something concrete, like 'our offer isn't visible enough'. I'd explain the reasoning behind the design, with research or test results, and offer to explore an alternative or test both versions with users. On [project], a client disliked our simpler home page; a quick test with five users showed it was faster to use, and the client approved it."

Show that you can take feedback without becoming defensive.

Treat it as a shared problem: understand the cost, find what matters most to users, and agree a plan. For example: "I'd ask which part is costly and why. Often it's a custom animation or component, and an existing design-system component gives most of the value. We'd ship that version now and plan the rest for later if data shows a need. On [project], we swapped a custom date picker for the platform's native one, shipped on time, and users had no trouble with it."

Interviewers want to hear that you respect engineering constraints without giving up on what users need.

Choose an app you really use, and be specific about why it works and what you'd change, with a user's reason. For example: "I think [a UPI payments app] is well designed for its users: the main action, scanning a QR code, is one tap away, and the payment confirmation is clear even for first-time users. One thing I'd improve is [a specific issue, like finding an old transaction], because [reason]. I'd test [my idea] by [method, such as a quick usability test with five users]."

Avoid general praise like "it's clean and simple"; interviewers want to see how you analyse a design.