How to Present Design Case Studies in Interviews

Speaker A: This audio is presented by Hacker Noon, where anyone can learn anything about any technology how to Present Design Case Studies in Interviews by Valeri Verva 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, categories, case study presentations, and project stories. And if there's one pattern I've seen over and over again, it's 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 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. 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? Care A shorter version Context Right pointing arrow Action Right pointing arrow Result this format works especially well when you need to explain a project quickly. Recommended case study 1. Context A N D 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 Constrained TS 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 A N D approach it's useful to User interviews, customer journey maps 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. Five Final solutions 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 1520 minutes to present a case study. During HM that time, the interviewer should understand the problem, your approach, your decisions and the outcome. For most projects, 1015 slides are enough. One to two slides for context and problem. One slide for goals and constraints. Two to four slides for research and exploration. Three to five slides for key decisions. One to two slides for results and conclusions. It's much better to explain three strong decisions in depth than quickly scroll through 30 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. Improve. 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 int e r v I e wremember to say I. Not just we teamwork matters, but interviewers need to understand your personal contribution. Instead of greater than we redesigned the flow, try greater than 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. Too many slidesi 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, uh, complete archive of your work. Your goal is to help someone understand the important things quickly. 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 roley 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. 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 greater than after hearing my presentation, would the interviewer be able to explain what greater than 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. Thank you for listening to this hackernoon story read by artificial intelligence. Visit hackernoon.com to read, write, learn, and publish.