UI/UX Designer interview questions and answers

I will use the appointment booking redesign for a chain of diagnostic labs. The problem was that many users started booking on mobile but called the centre instead of finishing. I reviewed call logs with the support team and interviewed eight patients. Most were confused by test names and did not know about fasting rules. I mapped the flow, sketched three options, and tested a clickable Figma prototype with six users. The final design grouped tests by symptom, showed fasting instructions upfront, and cut the flow from seven screens to four. Completed online bookings rose noticeably in the first month after launch.

I use what already exists before recruiting anyone. Support tickets, app store reviews, sales call notes and analytics funnels usually show where people struggle. Then I run five or six short remote interviews with existing users, recruited through the support team, twenty minutes each over video. For navigation questions I use a quick online card sort. I also do guerrilla testing: showing a prototype to people in a coworking space or to colleagues outside the product team. I share findings in a one-page summary with clips, so the team sees users struggle rather than just reading my opinion.

A wireframe is a low-fidelity layout, usually greyscale boxes and placeholder text, used to agree structure and content order without people getting distracted by colours. A mockup is a static, high-fidelity visual of the final screen, with real typography, colours, icons and images. A prototype is interactive: screens linked so people can click or tap through a flow. It can be low or high fidelity. In my college project, I did paper wireframes first, then Figma wireframes for the flow, tested a clickable low-fidelity prototype, and only then made polished mockups.

I write three to five realistic tasks, like find a flight to Goa under 6,000 rupees and book it, without using the exact words on the buttons. I recruit five or six users who match the target audience. During the session I ask them to think aloud, and I stay quiet unless they are completely stuck. I note where they hesitate, misclick or give up, and whether they complete each task. Afterwards I group issues by severity and frequency. Critical ones that block tasks go into the next sprint. I share a short video reel of key moments with the team.

I follow WCAG guidelines. Body text needs a contrast ratio of at least 4.5 to 1 against its background, and large text at least 3 to 1. I never use colour alone to show meaning, so error fields also get an icon and a message. Touch targets are at least 44 by 44 points on iOS and 48 by 48 dp on Android. Every form field has a visible label, not just placeholder text. I design visible focus states for keyboard users and give developers alt text and a logical heading order for screen readers. I also check layouts at larger system font sizes.

I start with foundations as variables and styles: a colour palette with semantic names like surface, text-primary and danger, a type scale, an 8-point spacing scale and elevation. Then I build components with auto layout and variants, for example a button with size, style and state properties, so designers pick options rather than detach and edit. Each component gets usage notes. I name components to match the developers’ code library so handoff is simple. In my last team, we reviewed new components weekly with a frontend developer, which stopped duplicate buttons and cards from multiplying.

I usually start mobile first, because the small screen forces me to decide what really matters. I use a grid, often four columns on mobile, eight on tablet and twelve on desktop, and design at key widths like 360, 768 and 1280 pixels. On mobile, content stacks in one column, navigation moves into a bottom bar or menu, and primary buttons sit within thumb reach. On desktop, I can show side-by-side panels and hover states, but nothing important should depend only on hover. I use auto layout in Figma so frames resize and I can check how text wraps.

Before launch I agree with the product manager on what success means and how we will measure it. For a signup redesign, that might be completion rate from start to verified account, time to complete, and drop-off at each step, plus support tickets about signup as a guardrail. Where traffic allows, we run an A/B test. Otherwise we compare the few weeks before and after, while watching for other launches or seasonal changes. I pair numbers with a few follow-up usability sessions, because metrics tell me what changed and sessions tell me why.

I use the ten well-known usability heuristics as a checklist. The ones I apply most are visibility of system status, like showing progress while a payment processes; match with the real world, meaning words users actually use, such as Pay now instead of Initiate transaction; user control and freedom, like an easy undo or back; consistency, so the same action looks the same everywhere; error prevention, like disabling past dates in a booking calendar; and recognition rather than recall, such as showing recent searches. When I reviewed a college fee portal, it failed several of these, which I documented with screenshots.

Handoff starts before the final file. I involve a developer during wireframes so we catch technical limits early. In the final Figma file, I use components from the design system, mark screens ready for development, and include every state: empty, loading, error, long text and permission denied. I add notes on interactions and animation timing, and link the flow to the ticket. Then I do a short walkthrough call with the developers. During build, I review staging and log differences as small tickets. I keep a shared list of questions so decisions are not lost in chat.

I would not start with screens. First I look at the funnel to find which step loses people, for example address entry or payment. Then I watch session recordings and read support tickets for that step, and run a few quick interviews. Common causes are surprise delivery fees shown late, forced account creation, long address forms and failed payments with unclear errors. Based on what I find, I would prototype fixes like showing total cost early, guest checkout, pincode-based address autofill and saved UPI options. I would test the prototype with users and then A/B test the biggest change.

The marketing head wanted a full-screen offer popup to appear as soon as users opened our app. I was worried it would annoy people who came to track an order. Instead of refusing, I suggested we test both: the popup on launch versus a banner on the home screen. I also showed session data that many users opened the app from order notifications. The test showed the banner got fewer clicks but the popup version had more app closures within ten seconds. We settled on showing the popup only to users without an active order.

For a farming advice app, I designed a clean dashboard with charts of soil and weather data, assuming farmers wanted detailed information. When we tested it in two villages near Nashik, most users ignored the charts and asked one question: what should I do today. Several preferred voice notes over reading. I redesigned the home screen around one daily action card in the local language, with a play button for audio, and moved the charts to a secondary screen. That changed how I work: I now test rough concepts with real users before polishing anything.

This happened with a custom animated date-range picker for a hotel booking app. The developer estimated it at two weeks. I asked what made it expensive, and it was mostly the custom animation and gestures. We agreed on what users actually needed: selecting check-in and check-out quickly and seeing the price per night. We shipped a version built on the platform’s native date picker, styled with our colours, with prices shown below. I added the custom interactions to the backlog. Usability testing later showed users were happy with the simpler version, so we never needed the custom one.

In my first design internship, I presented a dashboard in our weekly critique, and the lead designer said it looked attractive but she could not tell what the user should do first. It stung, because I had spent days on the visuals. I asked her to point to where her eye went first, and she showed that five cards had equal visual weight. I reworked it with one primary metric at the top, reduced colours to highlight only what needed action, and presented again the next week. Since then I ask for critique early, on wireframes, rather than on finished screens.

Our banking app’s new card screen used light grey text on white and small icons without labels. I ran a contrast check and several text styles failed WCAG AA. I also tested it with a colleague who uses a screen reader, and the icons were read out as button, button, button. I showed a short recording of that in the design review. It made the problem concrete. We fixed the contrast in the design system tokens, added labels to icons, and I wrote an accessibility checklist for our design reviews. The fix improved every screen that used those tokens, not just one.

A fintech client needed a new loan eligibility flow live in ten days for a partner launch. I skipped a full research phase and used existing support tickets to understand confusing points. I reused design system components so there was almost no new UI to build. I focused my time on the two hardest screens, the income input and the rejection message, and tested only those with four users over video calls. I cut custom illustrations and animations, which we added in the next release. The flow launched on time and the rejection screen got far fewer angry support calls than the old one.

I have three years of experience as a product designer in a fintech startup, with end-to-end ownership of two major flows and a design system. For similar product design roles in Bengaluru, the offers I have seen are roughly in the 14 to 18 lakh range. My current CTC is 12 lakh, and I am looking for around 16 lakh fixed. I am also interested in a budget for courses or conferences and a good laptop, since design tools are heavy. I am open to discussing the structure if the role has a clear growth path.

I have spent three years at a design agency, working on eight different clients. It taught me speed and variety, but most projects ended at handoff. I rarely saw how real users behaved after launch or got to iterate on my own work. In an in-house team, I can own a product area, run research continuously, see the metrics and improve the design over many releases. Your team also has a design system and researchers, which means I can go deeper on interaction design rather than doing everything alone. That is the growth I want next.

Yes, I am happy to do it. It is a fair way for you to see how I think, and it helps me understand the kind of problems your team works on. I would like to know how much time you expect me to spend, what format you prefer for the output, and whether I will get a chance to present and explain my decisions. If it is scoped for four to six hours, I can submit it within three or four days, since I am finishing my final semester projects this week.