Free download. Use it offline or customize it for your company.
Welcoming questions
Can you tell us about yourself and the products you have designed?
What to look for: A strong answer names product types, platforms, and the candidate's actual scope on each, while vagueness about what they personally owned versus what the team did is a red flag.
Sample answer: I've been designing software for about six years, starting with marketing sites at an agency and then moving into product work at two SaaS companies. Most recently I owned the design of a B2B invoicing platform: the dashboard, the entire billing flow, and the design system that grew out of it. Along the way I've shipped for web and iOS, and I've drifted steadily toward the research-heavy end of the work because I got tired of designing on assumptions.
Pick one shipped project: what problem did it solve, and how do you know it worked?
What to look for: Look for a clear problem statement and outcome evidence, whether metrics or research findings, since designers who cannot connect their work to results tend to design for portfolios.
Sample answer: Our invoicing product had a multi-step send flow that users abandoned constantly; support logged around 30 tickets a month about it. I mapped where people dropped in the funnel, interviewed eight users, and found the real problem was fear: no preview meant nobody trusted what the client would receive. The redesign centered on a live preview pane, and after launch, flow completion went from 62 to 84 percent and those support tickets nearly disappeared.
Role-specific and technical questions
Walk us through your process from a fuzzy product idea to a tested prototype.
What to look for: Strong candidates start by interrogating the problem and testing cheap artifacts early, while jumping straight to high-fidelity screens in Figma is a red flag.
Sample answer: I start by pressure-testing the problem itself: who has it, how do we know, and what does success look like? That usually means a short round of user interviews or a dig through support tickets and analytics. Then I sketch flows on paper or in FigJam before any pixels, because arguing about a flow diagram is cheap and arguing about a polished mock is not. Once the team aligns on a flow, I build a clickable Figma prototype at just enough fidelity to test the risky assumption, put it in front of five or six users, and iterate. High fidelity comes last, when the structure has survived contact with real people.
How do you run a usability test with limited time and budget?
What to look for: Look for scrappy but rigorous methods: five-user tests, task-based scripts, and recruiting from existing channels, rather than claiming testing is impossible without a research team.
Sample answer: Five users and a focused script gets you most of the signal. I write three or four realistic tasks, never leading questions, and recruit through whatever is cheapest: an intercept banner in the product, our customer Slack community, or asking support to flag willing users. Sessions run 30 minutes over a video call with the prototype, and I ask people to think aloud while I shut up and take notes. I can go from 'we should test this' to synthesized findings in under a week, and the pattern is always visible by the fourth session.
How do you decide when to follow the design system and when to break it?
What to look for: Strong answers default to the system and treat deviations as documented contributions back to it, while designers who casually create one-off components are a maintenance red flag.
Sample answer: The system wins by default, because every snowflake component taxes engineers and users forever. I break it only when the existing pattern measurably fails the use case, like a data table pattern that collapsed once we needed inline editing across 20 columns. Even then, I don't just deviate quietly: I prototype the new pattern, get it reviewed, and contribute it back to the system so the exception becomes the new rule. If a deviation isn't worth that process, it probably wasn't worth making.
How do you hand off designs so engineers build them faithfully?
What to look for: Look for handoff as an ongoing collaboration with edge states documented, plus implementation review, rather than tossing a Figma link over the wall.
Sample answer: Handoff starts before the design is done: I involve an engineer early so feasibility surprises don't appear at the end. The file itself covers the unglamorous states, empty, loading, error, overflow text, and responsive behavior, because those gaps are where implementations drift. I annotate interactions that a static frame can't show, walk the engineer through it live rather than just posting a link, and stay available during the build. Then I do a design QA pass on the staging build against the spec, which regularly catches spacing and state bugs before users do.
Critique one screen of our product right now. What would you investigate first?
What to look for: Strong candidates form hypotheses and name what data or research would confirm them, while candidates who confidently redesign on the spot without asking about users or context are a red flag.
Sample answer: Looking at this dashboard, my first instinct is that the visual hierarchy treats everything as equally important, so nothing is. But before touching it, I'd want to know what users actually come here to do: I'd pull click and scroll data to see which modules get used, and ask five users to show me their first two minutes in the product. My hypothesis is that two of these six widgets carry 80 percent of the value. I'd rather validate that and cut ruthlessly than reshuffle boxes based on my taste.
How do you make sure your designs meet accessibility standards?
What to look for: Look for accessibility treated as a design-time habit with specific WCAG practices, not a compliance pass bolted on before launch.
Sample answer: I bake it in at design time rather than auditing at the end. Concretely: every color pair gets checked against WCAG AA contrast before it enters the file, touch targets stay at 44 pixels minimum, nothing communicates through color alone, and I annotate focus order and screen reader labels in the handoff for interactive components. I also keyboard-walk the staging build myself during design QA. On my last team I added contrast-checked color tokens to the design system, which meant accessibility stopped depending on each designer remembering.
Behavioral and culture fit questions
Tell us about a design you loved that data or research killed. What did you do?
What to look for: The best answers show ego detachment and genuine curiosity about why the design failed, while lingering resentment toward the data or the users is a red flag.
Sample answer: I designed a command palette for our analytics tool, a beautiful keyboard-first interaction I was genuinely proud of. Usability tests were brutal: our users were finance people, not developers, and not one of the eight participants discovered it or wanted it once shown. It stung for a day. Then I got interested in what the tests revealed instead: people wanted fewer options visible, not faster access to all of them. That insight became a simplified navigation that tested dramatically better, so the dead feature ended up funding the right one.
Describe a productive conflict with a product manager or engineer.
What to look for: Look for disagreement resolved with evidence or a cheap test rather than seniority or persistence, and for a relationship that came out stronger.
Sample answer: A PM and I disagreed hard about onboarding: he wanted a six-field signup form to feed sales data, I argued every field cost us signups. Neither of us actually had evidence, just conviction, so instead of escalating we agreed to test it: two-field version against the six-field version for two weeks. The short form converted 22 percent better, and sales got the extra fields moved to a later, post-activation prompt where completion was fine. The useful part wasn't winning; it was that 'let's test it' became our default way of disagreeing after that.
How do you handle shipping a compromise you find ugly but pragmatic?
What to look for: Strong candidates accept real-world constraints without becoming cynical, and they track compromises for future improvement rather than relitigating or silently seething.
Sample answer: I've made peace with the fact that shipped and imperfect beats polished and theoretical. When a deadline forced us to launch a settings page as a long undesigned list instead of the organized redesign I'd proposed, I made sure the compromise was at least usable and accessible, then logged the gap in our design debt list with evidence of the friction it caused. Two quarters later that evidence got the redesign prioritized. What I won't compromise on quietly is anything that misleads users; that's a different conversation.
Tell us about a time you had to advocate for the user when the business was pushing the other way.
What to look for: Look for advocacy grounded in evidence and framed in business terms, while both silent compliance and self-righteous blocking are red flags.
Sample answer: Growth wanted to make the cancellation flow harder to find, buried two menus deep, to reduce churn. I pushed back, but not on aesthetics: I pulled data showing that users who struggled to cancel disputed charges at triple the rate and left angrier reviews, so the churn would just move somewhere more expensive. I proposed an alternative: keep cancellation findable but add one well-designed save offer screen with a genuine discount. Cancellations dropped 9 percent anyway, and we kept our reviews clean. Framing the user's interest as the business's interest is usually the winning move.
Problem-solving and case questions
Onboarding completion is 40 percent and product wants 70. How do you approach it?
What to look for: Look for diagnosis before solutions: funnel analysis to locate the drop, research to explain it, and skepticism about whether 70 is even the right target.
Sample answer: First I'd break that 40 percent apart, because 'onboarding completion' hides everything useful: step-by-step funnel data will show whether people die at account creation, at the empty dashboard, or at some specific setup step. Then I'd watch five to ten session recordings and run a few interviews at the biggest drop point to learn why, since the fix for confusion is very different from the fix for lack of motivation. I'd also gently question the 70 percent target: if half our signups are tire-kickers from a broad campaign, no design fixes that. Then I'd ship the single highest-leverage fix as an A/B test rather than redesigning the whole flow blind.
Support tickets show users cannot find a core feature. Walk us through your fix process.
What to look for: Strong candidates triangulate tickets with analytics and quick discoverability tests, and validate the fix, rather than immediately promoting the feature to the top level.
Sample answer: I'd read the actual tickets first, twenty or thirty of them, because 'can't find it' can mean bad navigation labels, wrong mental model, or users who don't know the feature exists at all. Then analytics: what percentage of active users ever touch the feature, and what paths do the successful ones take? A quick tree test or first-click test with the current navigation usually pinpoints the failure in a day or two. My bet in these cases is usually a labeling problem, we named the feature in our language instead of the users'. I'd test the fix the same way before shipping, then watch ticket volume and feature adoption to confirm it worked.
You have one week of design time for a feature engineers need specs for in three days. What do you do?
What to look for: Look for ruthless scoping and staged delivery under pressure, with risk flagged honestly, rather than heroics or handing over unreviewed work.
Sample answer: I'd negotiate the sequence, not the deadline. Day one: align with the engineer on what they need first, which is usually the data model and core flow, not the polish, and get a flow diagram plus rough wireframes of the critical path into their hands. Days two and three: spec the primary screens and states using existing design system components exclusively, because now is not the time to invent. The remaining days I run behind the build, detailing secondary states and doing design QA as they go. I'd also tell the PM plainly which corners we cut and what a fast-follow polish pass should cover, so the compromise is a decision, not an accident.
Leadership wants to copy a competitor's popular feature into our product. How do you respond as the designer?
What to look for: Strong answers investigate the underlying user problem and our own users' context before copying, while both blind execution and reflexive resistance are red flags.
Sample answer: I wouldn't fight the request, but I'd reframe it: what user problem does that feature solve, and do our users have it? Their product serves a different audience with different workflows, so the feature might not transplant. I'd spend a few days on discovery, checking whether our support tickets, research notes, or analytics show demand for that job to be done. If the need is real, great, we design our own solution to the problem rather than cloning their UI, because their solution carries their constraints. If it's not there, I'd bring that evidence back with what our users are actually asking for, which is a more useful conversation than yes or no.
Generate custom UI/UX Designer interview questions
Need questions tuned to your industry, seniority level, or interview stage? Describe the role and our AI interview questions generator will draft a set in seconds.
