Design & UX Interview Guide: Portfolio, Process & Problem-Solving Questions
Design interviews are unique because they’re heavily portfolio-based.
You’ll get asked about:
- Your portfolio projects (walk through them)
- Your design process (how do you think?)
- Design decisions and tradeoffs
- Your collaboration approach
- Problem-solving under constraints
Here’s how to nail them.
What Design Interviewers Are Really Asking
Behind every design question:
- Is your work good? (Portfolio quality)
- Do you think strategically? (Not just making things pretty)
- Can you explain your decisions? (Rationale, not just aesthetics)
- Do you understand users? (Research + empathy)
- Can you work with constraints? (Budget, timeline, technical limits)
- Can you collaborate? (With PMs, engineers, stakeholders)
- Do you ship? (Or do you just beautify comps?)
Part 1: Portfolio Preparation
Your portfolio is your resume. It matters more than what you say.
Portfolio Structure
Best practices:
- [ ] 3–5 strong projects (better than 10 weak ones)
- [ ] Each project: context → problem → process → solution → outcome
- [ ] At least one collaborative/shipped project (not just personal work)
- [ ] Mix of: product design, interaction design, process-heavy, iterative projects
- [ ] Avoid: overly trendy, poor writing, unclear problems
What a Strong Project Looks Like
Project: Mobile Checkout Redesign
Context (1 slide):
“We had an existing mobile checkout. Average checkout completion was 65%. Industry standard is 80%.”
Problem (1 slide):
“I conducted 10 user interviews and found: users were confused about what happened after they entered their card info. They weren’t sure if payment went through until the confirmation screen. That uncertainty led to cart abandonment.”
Process (2–3 slides):
"I sketched 3 approaches: inline confirmation, per-step progress, or modal confirmation. I tested these with 8 users using paper prototypes. Modal confirmation had the highest clarity score.
I then designed high-fidelity mockups. I tested a few interactions: immediate button disable (too fast—people didn’t see feedback), spinning button (confusing), or progress bar (clear). Users preferred progress bar."
Solution (2–3 slides):
“Here’s the new design with progress bar. User flow changed from [old] to [new]. Interactive elements now [specific improvements].”
Outcome (1 slide):
“After launch, checkout completion improved from 65% to 78%. Cart abandonment reduced 18%. This drove $500k additional annual revenue.”
Why this works:
- Clear problem statement
- User research evidence
- Iterative process (not just one solution)
- Design decisions with rationale
- Shipped work with real outcomes
Portfolio Don’ts
❌ Don’t include work where you don’t understand the outcome
(You should know: “Why did you make this choice?” and ideally “What happened after?”)
❌ Don’t make it about aesthetics alone
(Aesthetics matter, but strategy > aesthetics. Show the thinking.)
❌ Don’t include confidential work
(You can show it but anonymize it: “A B2B SaaS company” instead of company name)
❌ Don’t have too many projects
(5 strong projects > 15 so-so projects)
❌ Don’t have typos
(Design is in the details. Typos scream “I didn’t care”)
Part 2: Design Interview Questions + Answers
Question 1: “Walk Me Through This Project”
They’re not asking for a description. They’re listening for:
- Do you articulate the problem clearly?
- Is there evidence of research?
- Did you iterate or just do one version?
- Can you explain design decisions?
- Did it actually launch and impact anything?
Your answer structure (5 min per project):
90 seconds: Context + problem
“I worked on a patient booking system for a healthcare clinic. The existing system was 15 steps to book. Most patients were booking by phone instead of online (despite the app existing). Our goal was to get 60% of appointments booked online instead of 40%.”
2 minutes: Process
"I started with 12 user interviews with actual patients. I learned the biggest friction was the insurance section—patients didn’t understand which insurance fields to fill. I also did a heuristic review of the current flow and found three screens where we lost people.
I sketched three different structures: one that grouped by visit type, one that grouped by patient preference (quick/detailed), and one that was just simpler and shorter.
I tested these low-fidelity sketches with 8 users. The shorter version won because patients didn’t want to input optional info."
2 minutes: Solution
“So I designed the new flow with fewer steps. Here are the big changes: [point to design]. Biggest interaction change: here we removed the radio buttons and made it a single choice flow.”
30 seconds: Outcome
“We launched it and online bookings went from 40% to 58% of total appointments. That removed workload from our phone team and decreased booking time by 5 minutes per call.”
Question 2: “How Do You Approach Design Decisions When You Disagree With Stakeholders?”
What they’re testing: Can you hold your vision while respecting input?
Your answer:
"This actually happened with [project]. The PM wanted to add a feature flag in the checkout to let users choose between two checkout flows. I thought it would confuse users—you want one clear path.
I wasn’t dismissive. I said: ‘I understand why you want this. But I’m worried it’ll reduce our conversion rate. Can I test it with users first?’
We tested with 10 users. They were indeed confused. One user said ‘Why are you asking me what type of checkout I want? I don’t know what these are.’
I shared the research with the PM. We said: ‘Let’s ship the simpler version now. We can AB test later if we want.’ PM was satisfied because it wasn’t a rejection—it was ‘let’s test first.’
I think this is the right approach: have a point of view, but let data/research lead the decision. Don’t be stubborn, but don’t be a pushover either."
Question 3: “Tell Me About a Constraint You Faced and How You Handled It”
What they’re testing: Are you resourceful? Or do you just say “no, I need more time/budget”?
Your answer:
"I was designing a new mobile app feature and engineering said they could only allocate 2 weeks, not the 4 I requested. I had two options: push back or get creative.
Instead of pushing back, I asked: ‘What if we shipped version 1 as a basic version? Then we build the advanced version later.’
That unlocked it. I designed version 1 in 2 weeks with core functionality. It shipped. Users loved it (70% adoption). Then I designed v2 with the advanced features later.
Constraint forced us to think about what actually mattered. Turns out, the basic version was enough.
I think constraints are often good for design. They force prioritization."
Question 4: “Design-Specific: How Would You Approach [Design Problem]”
Example: “How would you design a better onboarding for a note-taking app?”
Your answer structure:
"Before I sketch, I’d ask some questions:
- Who are we designing for? (Students? Professional note-takers? Casual users?)
- What’s the biggest friction right now? (Are people not activating? Or activating but not coming back?)
- What’s our success metric? (First note within X minutes? Aha moments?)
- What constraints do we have? (Timeline, engineering capacity?)
Based on assumptions that [you make reasonable guesses], I’d probably:
- Research: Talk to 5–10 users. What’s their note-taking workflow? What’s easy/hard about your app vs. competitors?
- Ideate: Create 3 different onboarding experiences. One is minimal (just templates), one is guided, one is hands-on. Each targets different user types.
- Prototype: Build quick prototypes (wireframes are fine, not full design). Test with users.
- Design: Once I know which approach resonates, I’d design it in full.
I’d probably lean toward [specific approach] because [rationale based on user understanding]."
Why this works:
- You ask clarifying questions (shows strategic thinking)
- You outline a process (not just jumping to solution)
- You show user research is first (not aesthetics)
- You’re thoughtful about constraints
Question 5: “How Do You Measure If Your Design Was Successful?”
What they’re testing: Do you care about outcomes? Or just aesthetics?
Your answer:
"It depends on what we optimized for. Here are examples:
For onboarding: I’d measure time-to-first-aha. Did users activate faster? Are they coming back?
For checkout: I’d measure conversion rate. Did we increase completed purchases?
For navigation: I’d measure: time-to-task. Can users find what they need faster?
For the [specific project], our metric was [metric]. Post-launch, we saw [improvement].
I also care about qualitative feedback. I look at user comments. Do they get it? Do they feel the design is intuitive? Numbers are half the story, but user reaction matters."
Design Interview Scenarios
Scenario 1: You’re Transitioning From Graphic Design to UX
Problem: Interviewers worry graphic designers don’t understand user research or usability.
Your approach:
"I’ve been a graphic designer for [years], which taught me refined aesthetic sense and visual communication. But I realized I wanted to understand users better, not just make things pretty.
Over the past [time], I’ve been learning UX through [courses, personal projects, freelance work]. I did a project where I [example of user research or usability testing].
I’m not abandoning my design skills. I’m combining them with a focus on user needs and outcomes."
Scenario 2: You Don’t Have Shipped Products
Problem: Most of your portfolio is personal projects or academic work, not shipped products.
Your approach:
"Most of my portfolio is personal/academic work because I haven’t been at companies with shipped products yet. But here’s what’s relevant:
In [project], I went through a full process: research, iterations based on feedback, designing for constraints. These skills transfer.
I’m also seeking a role at a company where my first project will be a shipped product. That’s what will complete my experience."
Scenario 3: You Made a Bad Design Decision
Problem: A feature you designed wasn’t well-received or didn’t ship.
Your approach (ownership):
"I designed [feature]. In retrospect, I should have done more user research before designing. I went with my gut instead of evidence.
Post-launch, users didn’t engage with it. I learned: my gut is usually wrong without data. Now I front-load research before designing.
Here’s what I’d do differently [describe new process]."
Design Portfolio Platforms
Good platforms for portfolio:
- [ ] Figma (easy to share interactive prototypes)
- [ ] Adobe Portfolio
- [ ] Webflow (if you want custom web design)
- [ ] Behance (if you want simple case studies)
Key: Make it easy to view on desktop + mobile. Make it fast to load.
Design-Specific Interview Tips
1. Bring Your Portfolio Printouts
Some designers design on computer and present on screen. But bring physical printouts too. Shows confidence + gives them something to hold.
2. Be Ready to Discuss Your Process
Interviewers often ask: “Walk me through how you’d redesign [our product]”
Have a quick 5-step process ready:
- Understand problem (research)
- Ideate solutions (sketches)
- Test with users (quick prototypes)
- Refine (high-fidelity)
- Measure (ship + analyze)
3. Ask About Their Design Process
Ask:
- “How do you think about design process here?”
- “How much do you prioritize user research?”
- “What’s the biggest design challenge you’re facing?”
Shows you care about the culture of design, not just the job.
Common Design Interview Mistakes
❌ Only focusing on aesthetics
(“I made it pretty” is not a design story)
❌ Not being able to explain your decisions
(You should have a reason for every choice)
❌ Portfolio with too much personal work, no shipped products
(One or two is fine, but show some real-world impact)
❌ Not asking questions during the problem-solving round
(“Here’s what I’d design” without asking context = jumping to solution)
❌ Not knowing the outcome of your work
(“I shipped this a year ago but I don’t know what happened” = concerning)
Key Takeaways
- Portfolio is your resume (5 strong projects > 15 weak ones)
- Tell a clear story (problem → process → solution → outcome)
- Show research, not just aesthetics (User research first)
- Have a thinking process (Not just answers)
- Know your numbers (Did conversion improve? Adoption? Time reduction?)
- Be ready to explain decisions (Not just “I thought it looked good”)
- Show iteration (A/B tests, user feedback, refinement)
- Demonstrate collaboration (You work well with engineers, PMs)
Design interviews are testing your thinking as much as your portfolio. Show clear strategy, real outcomes, and thoughtful explanation—and you’ll stand out.
Next: You’ve mastered the design interview. Now explore the full interview cycle with Interview Preparation Complete Guide or Interview Day Checklist.