Recently at Dialpad, I attended several case study presentations from product design candidates. Some of them were truly impressive. You could tell the designers had solid thinking, clean visuals, and a strong grasp of process. But even the best ones often missed key parts of the story.
That’s a shame, because leaving those pieces out or framing the case study poorly can make a big difference in how the work is perceived. In some cases, it can even cost you the role. Most candidates know the steps of the design process, but many underestimate how critical storytelling is when presenting their work.
After watching multiple presentations back-to-back, a few patterns became clear to me.
Complexity can backfire
One candidate presented a complete dashboard redesign. His visual design skills were great, and he clearly knew what he was doing with design patterns. The interactions felt thoughtful, and he handled intricate flows confidently.
But the problem was that the redesign was too broad. He couldn’t clearly explain what the main use case was or which user problem he was solving. On top of that, the product itself belonged to a complex industry that was difficult to understand, and it became obvious that even he wasn’t entirely sure what the core issue was.
The result was that the audience lost clarity on what the project was really about. It didn’t matter how nice the visuals were or how sophisticated the flows looked. Without a focused story that connects back to a clear user problem, the work loses impact.
Complexity only works when every part of your narrative is anchored to purpose.
Stick to one flow
Once you realize complexity can hurt your story, the next step is to simplify it. The strongest candidates I saw focused on one user flow. That’s all it takes. Trying to show an entire app redesign spreads your story too thin. You end up touching everything but explaining nothing in depth.
A better approach is to go narrow and deep. Focus on a single flow that captures a real problem and walk your audience through how you approached it. Here’s a structure that works:
- Who is the user
- What’s their pain point
- What does the current experience look like
- What lo-fi solutions did you explore
- What did testing reveal
- Why did you go with the final direction
- How did you collaborate with engineers
- What changed after launch
- What’s next
- What impact did it have
When you present this way, you’re not just showing screens. You’re walking people through how you think, how you collaborate, and how you make trade-offs.
Be transparent about AI and avoid overdesigning
Another pattern I noticed is the growing use of AI in case studies and portfolio sites. That’s not a bad thing. This article, for example, was improved using AI, and you probably noticed it. What matters is transparency.
If you used AI to help with your visuals, copy, or portfolio design, say it. It shows curiosity and adaptability, which are great qualities in product design. But be careful not to let flashiness take over substance.
Some candidates overuse motion, effects, and overproduced visuals that look impressive at first but make it harder to follow the actual process. A strong case study doesn’t need heavy motion design or fancy transitions. It needs structure, clarity, and thoughtful storytelling.
You’re being evaluated for how you solve problems, not how many effects you can apply. Keep the focus on what matters most: the user, the decisions, and the impact.
Be visual. Always.
Once you’ve built clarity and structure, your next job is to make your presentation visual. Many candidates rely too much on text to explain their process. That makes it harder to connect.
If you’re improving an existing experience, show what the current one looks like first. Even if you don’t have access to the real app, recreate it from memory. Show the issue. Let people see what you’re fixing. Then move to your design explorations and walk them through what changed and why.
Being visual doesn’t just make your presentation prettier. It shows empathy for your audience. You’re guiding them step by step, helping them understand context and reasoning without needing to read paragraphs of text. That’s what great design storytelling is about.
Final thought
Being part of these presentations made me reflect a lot on my own practice. I realized how easy it is for any of us, even experienced designers, to fall into similar traps. We focus on solving the problem but sometimes forget to clearly frame it when presenting to stakeholders.
This experience reminded me to be more intentional about how I structure my own case studies and internal reviews:
- Make sure I understand the user problem deeply before jumping into solutions
- Present the story visually, not just verbally
- Be clear about the decisions and trade-offs
- Measure the impact of my designs and follow up to learn from real outcomes
At the end of the day, we’re all constant learners. Watching others present reminded me how much growth comes from paying attention to how we tell the story, not just what we built. Every presentation is a chance to improve how we communicate, connect, and deepen our understanding of the products and industries we work in.