How to Present Design Case Studies in Interviews

Over the past few years, I've gone through hundreds of interviews in English while looking for opportunities abroad. I've presented my work to designers, managers, product leaders, and design leads from different countries and companies. At the same time, I interview designers myself as a Design Lead and regularly review portfolios, case study presentations, and project stories. And if there's one pattern I've seen over and over again, it's this: Many strong designers don't fail because they have weak projects. They fail because they don't know how to explain their work clearly. Below are a few recommendations that can help make your case studies more structured, clear, and convincing. Here’s the Main Principle In an interview, people evaluate more than just the quality of your designs. They also assess your thinking process, problem-solving approach, ability to navigate ambiguity, and impact on outcomes. That's why it's important to explain not only what happened , but also how you got there . The interviewer wants to understand: the problem you were solving; how you made decisions; the constraints you worked within; what your personal contribution was; what impact your work had. Pro Tip: Use STAR or CAR Both frameworks help you stay focused and tell a clear story. STAR Situation — context and problem What was happening? Why did this challenge exist? Task — goal What was the business or product objective? Action — actions What exactly did you do? What decisions did you make? What research did you conduct? Result — outcome What changed after launch? CAR A shorter version: Context → Action → Result This format works especially well when you need to explain a project quickly. Recommended Case Study Structure 1. Context and Problem Start by answering a few basic questions: What was the product? Who were the users? What problem existed? Why was it important to solve? If the project was built from scratch, mention it. If the project is under NDA or has not launched yet, make that clear at the beginning. 2. Goals and Constraints Explain the boundaries of the project: timelines; resource limitations; technical constraints; domain complexity; multiple stakeholders. This helps interviewers understand the scale of the challenge. 3. Research and Approach It's useful to show: user interviews; customer journey maps (CJMs); competitor analysis; quantitative data; usability testing; hypotheses. Even a small amount of research demonstrates that your decisions were based on evidence rather than assumptions. 4. Decision-Making Process This is often the most important part of a case study. Don't just show screens. Explain: which options you considered; why certain ideas were rejected; what trade-offs you had to make; which decisions were the most difficult. This is where your design thinking becomes visible. 5. Final Solution Show the final user flow and key screens. You don't need to explain every button. It's far more important to demonstrate how the solution addressed the original problem. Presentation Size Matters One of the most common mistakes is trying to show the entire project. Remember: you usually have around 15–20 minutes to present a case study. During that time, the interviewer should understand the problem, your approach, your decisions, and the outcome. For most projects, 10–15 slides are enough: 1–2 slides for context and problem; 1 slide for goals and constraints; 2–4 slides for research and exploration; 3–5 slides for key decisions; 1–2 slides for results and conclusions. It's much better to explain three strong decisions in depth than quickly scroll through thirty screens without explaining why they exist. 6. Results The ideal outcome is measurable impact. For example: conversion growth; reduced task completion time; increased feature adoption; improved business metrics. If you don't have numbers, that's perfectly fine. In that case, explain: how the project will be launched; rollout stages; validated hypotheses; insights from usability testing. If the project is still in development or protected by NDA, explain how success will be measured after launch. The key is showing a clear connection between your solution and the expected outcome. What Matters Most During an Interview Remember to say "I", not just"We" Teamwork matters, but interviewers need to understand your personal contribution. Instead of: We redesigned the flow. Try: I proposed a new flow structure, created prototypes, and ran usability tests. Show Impact A strong case study is not a story about screens. A strong case study is a story about a problem, a solution, and a result. Even if the project hasn't launched yet, explain how you plan to measure its effectiveness. Common Mistakes I See in Interviews Over the years, I've noticed that most mistakes have nothing to do with design quality. More often, the problem is how people tell their story. Mistake #1. Too Many Slides I once interviewed a candidate who brought a presentation with 140 slides . I'm sure they put a huge amount of work into the project. The problem was that interviews have a limited time. Ten minutes into the presentation, we were still on the first few slides. At that point, it was obvious we wouldn't get to the most important parts. An interview is not a thesis defense or a complete archive of your work. Your goal is to help someone understand the important things quickly. Mistake #2. An Overly Long Introduction Another candidate started their story from childhood. They explained what they were interested in at school, how they chose a university, and how they entered the profession. Several minutes later, I still didn't know why they were a good fit for the role or what problems they were good at solving. No matter how interesting your journey is, interviewers need to understand your professional value quickly. Don't make them wait too long. Mistake #3. Showing Only Beautiful Screens Sometimes a presentation looks like a Behance project: lots of visuals; beautiful mockups; polished interfaces. But it's completely unclear: what problem was being solved; why certain decisions were made; what changed after launch. Beautiful screens rarely get someone hired. Understanding how you think often does. Mistake #4. Getting Lost in the Details Many designers try to tell absolutely everything. Every meeting. Every iteration. Every screen. Every comment from a stakeholder. But interviewers don't need a complete project diary. They need a story. Choose a few important decisions and explain them deeply. That's much more powerful than covering everything superficially. Final Check Before the Interview Before presenting any case study, ask yourself: After hearing my presentation, would the interviewer be able to explain what problem I solved, what decisions I made, and what impact I had? If the answer is "yes", your case study is ready. One Last Thing An interview is not a presentation of screens. It's a presentation of how you think. If people remember your decisions, your reasoning, and your impact on the product, you've told the story well. If they only remember the number of screens or the length of the presentation, the focus was probably in the wrong place. \