A product designer I know spent three weeks drilling Figma shortcuts before her Google interview. She felt good going in. The interview itself had exactly zero questions about Figma. What it had was an hour of questions about how she made decisions, how she handled pushback from engineers, and what she would do if she couldn’t run user research before a deadline.
Design interviews are less about craft than most designers expect, and more about process and communication than almost anyone prepares for.
What interviewers are actually measuring
Before running through specific questions, it helps to understand what categories they’re testing. Most design interviewers are evaluating five things:
- Whether you have a clear, defensible design process
- How you handle constraints (time, budget, incomplete data)
- How you collaborate with people who aren’t designers
- Whether your visual decisions are intentional, not just aesthetic
- Whether you can take feedback without becoming defensive
A few companies also add a sixth: accessibility. This one trips people up because it sounds like a compliance checkbox question, but experienced interviewers want to know if you think about it proactively during design, not just at the audit stage.
Design process questions (and what the real answer is)
“Walk me through your design process.” The trap here is being too generic. “I do discovery, then wireframes, then hi-fi, then testing” describes the steps but tells the interviewer nothing about how you actually think. Better answers get specific about the tradeoffs you make and why. If you skip a step, say so and say why. If you do discovery differently depending on project type, explain that.
“How do you decide when a design is done?” There’s no single right answer, but “when the client approves it” is the wrong one. What interviewers want is some version of: done relative to what goal, measured how. Bring in a specific example from past work if you have one.
“Tell me about a design decision you regret.” This is less about the mistake and more about how clearly you can see your own work in retrospect. Candidates who say “I’d do everything the same” tend not to move forward. Candidates who over-explain a small thing as catastrophic also don’t do well. The answer that works is honest, specific, and shows what you actually changed as a result.
User research questions
“How many users do you need for usability testing?” The oft-cited answer comes from Nielsen Norman Group’s research suggesting that 5 to 7 participants typically surface around 80% of usability issues in a given interface. That’s a useful benchmark for moderated sessions, though the right number depends on the variation in your user base. Mentioning that you’d adjust based on context goes over better than reciting the number by itself.
“What do you do when you can’t run user research?” This is a constraint question disguised as a research question. The interviewers asking this have usually been in exactly this situation. They want to know if you’ll (a) refuse to work without perfect information, (b) invent user data, or (c) make reasonable assumptions clearly documented so they can be tested later. Option (c) is what they want.
“How do you synthesize research findings for stakeholders who don’t read reports?” A surprisingly common question at mid-size companies and up. What they’re really asking is: can you translate. The best answers involve a specific format they’ve used (a one-pager, a short video, a journey map walk-through in a meeting) and some observation about what made it work or not.
Visual design and systems questions
These questions are more technical than the others and often come from a design system lead or a senior IC designer rather than a hiring manager.
“How do you approach typography in a new product?” A reasonable starting point: limit yourself to two or three typefaces maximum. Within that, establish a clear hierarchy (display, body, caption) before choosing the faces themselves. Color-independent readability should be testable before anything else locks in.
“What’s your approach to color contrast?” The concrete answer here is WCAG 2.1 standards: 4.5:1 contrast ratio for standard text, 3:1 for large text (18pt and above, or 14pt bold). The better answer adds that you check contrast in context, not just against a white background, because real interfaces have layered colors. Accessibility standards from the W3C Web Accessibility Initiative are the right citation here if you want to show you’re working from the actual source.
“How do you design for internationalization?” German text expands roughly 30% over English in most strings. Arabic and Hebrew require full RTL layout support. Japanese and Chinese require different type scale logic entirely. If you’ve never designed for these, say so honestly and explain how you’d approach it. Interviewers at global-market companies have heard enough made-up answers to this to appreciate the honest one.
Portfolio questions you’ll almost certainly get
Most design interviews include a portfolio walk. The questions are usually some version of: “Why did you make this decision?”, “What would you change now?”, and “What was the outcome?”
Bring 3 to 5 case studies. Not 10. If you have 10 things to show, pick the ones where you have the clearest story about the problem, your role, and the result. One good case study you can narrate fluently is worth more than four you fumble through.
A thing I see come up repeatedly in feedback from designers who didn’t get offers: portfolios that show beautiful final screens but skip the messy middle. The exploration, the dead ends, the version the client hated. Interviewers know that good design doesn’t arrive fully formed. Showing your process is more interesting than showing the polish.
Accessibility and the advanced stuff
Touch targets. The minimum recommended touch target size is 44×44 pixels, per Apple’s Human Interface Guidelines. This matters on mobile-first products and increasingly on tablet-targeted B2B software. If you haven’t internalized this, it’s worth doing before a design system interview.
Interviewers at companies with established design systems sometimes ask about component versioning, design token architecture, or how you handle component deprecation. These are less common outside of staff-level interviews, but worth knowing about if the job description mentions “design systems” anywhere.
The 2024 Stack Overflow Developer Survey found that collaboration between designers and developers remains one of the most commonly cited friction points on product teams. A lot of the questions in a design interview are trying to figure out whether you’ll make that friction better or worse. Coming in with examples of how you’ve worked well with an engineering team goes a long way.