Storytelling, not reporting. Engaging case studies with examples

Published in

Bootcamp

7 min readAug 1, 2023

The problem with report-like case studies is that they're neither effective nor engaging. They take lots of effort to write but turn off hiring managers almost instantly as they've seen the same cookie-cutter process over and over again.

To tell an engaging project story, and convey your unique problem-solving process try to follow a ‘Story arc’. The story arc is a structure found in literature & film that represents a progression of a narrative through 3 stages: beginning → middle → end. When applying it in the case study, replace it with 1️⃣ Context → 2️⃣ Story → 3️⃣ Results.

Let’s go through it one by one.

1. Context

Part one. Context highlight illustration

1.1 A title and cover image.

First, you judge how nice, then you judge how wise

Any great story starts from a preview. In the movies from a poster, in literature from a book cover. The same applies with case studies, a cover image is your shot for a strong first impression. Think of it as of dribbble upload. It should grab attention and explain what this project is about. The more appealing it is, the more likely readers will stick around to learn about your project.

The second hook element is your title. It should be as tangible and intriguing as possible. To make it tangible highlight the project subject, the challenge, and the impact.

👉 Title example: Redesigning POS user experience for 1,2m DAU waiters.

This title includes the subject (POS for waiters), the challenge (implying that lots of daily users have strong habits, so the goal is to improve UX, but not break the habits), and the impact (1,2 DAU). The 'challenge' here is a hook that targets to spark curiosity.

💡Tip: Think how your project title can imply an intriguing challenge that prompts readers to read the full story.

1.2 About the project

Think of it as an extension of your project title that expands and actualizes the problem. Just like in the title you want to share: the subject, the challenge, and the impact:

A one-liner about the product.
The problem or reason for running a project.
A goal you’re targeting to achieve or achieved outcomes/impact.

👇 Example:

[Product X] is a family of POS products built on premise for thousands of restaurants over 30 years.
This made a business not sustainable, enabled a range of inconsistencies, and forced supporting multiple devices, and platform architectures.
I designed the first design system using universal cross-platform visual language but preserved a familiar UX logic to avoid breaking habits.

1.3 Team and your role

If it was a collaboration (which is a skill you always want to highlight in the product design portfolio), make sure you mentioned your key responsibilities.

👇 Example:

Team: Design lead & 2 senior designers.
My role was to: Analyse existing design patterns and come up with a consistent and adaptive design system library.

💡Tip: You might also want to frame your project context in the form of TL;DR. This format might look even more appealing to read for busy design managers.

2. Story

2.1 Research insights

The classic mistake here is that designers often start laying out the design process and each step they took. Imagine if you were about to read an intriguing book, but instead of learning about the hero and their path, the author would start talking about their book writing process. Would it be a book you’d want to continue reading? The bottom line here is:

Don’t start by saying what research methods you’ve used. That’s reporting. Drive your story with the key research insights.

E.g. What were your AHA moments that defined your project direction? The insights you’ve uncovered will tell a story. Not research methods that design managers see everywhere. But don’t get me wrong, do mention research methods, just not in the first place, not as section titles.

*Research insights example by Martin Jancik*

2.2 Ideation

That’s a peak of the story arc and the juiciest part of a case study. It communicates your thinking — essentially what you’re being hired for. You don’t have to make it look perfect. The design process is messy and authenticity is your ace:

Share whiteboarding sketches.
Share workshop sticky notes.
Share concepts you formed.

Finally, share what and why you chose as the final concept. Did you select it based on your critical thinking or using exercises like the impact/effort scale?

*Sketching session example by Chris Paniati*

2.3 Design

Once the solution concept is communicated, naturally the reader gets curious about the details. That's when you want to introduce your design details. There are 3 levels to communicating your designs:

Remind the context
Share your final designs
Zoom into the details you’re most proud of.

1. Remind the context:

Reading up to this point makes it really easy to forget the key research insights or learnings. That's why it's worth reminding the reader of the key scenarios/user stories you were designing for. Again, focus on the story, not reporting.

👇 Example:

Do: The waiter wanted the POS to display the order status, so they can communicate how long each meal prep will take to the customers.
Don’t: Here are IA and flowchart images.

2. Share your final designs

Right next to the context, you want to attach Figma prototype links, or videos pointing out your key design solutions. I personally prefer to see videos/GIFs over prototypes because prototype links typically have too many hotspots which can be distracting. You can also use before/after screenshots, however, they are static and don't communicate the full flow. So, I'd only use it to communicate principal decisions.

*Design solution example by Lukas Otsuka*

3. Zoom into the details you’re most proud of.

The final layer is details, where you can share bits you’re most proud of. For example micro-interactions, empty states /edge cases, experience delights, or witty copy. This step is optional, but if your strong power as a designer lies in polishing these details, then you definitely wouldn’t want to skip it.

2.4 Validation

The final piece of the design story is how your design validation went. To keep it story-focused, keep focusing on the key learnings.

What was your hypothesis?
Top testing insights and how you’ve updated your design.

Again, don’t mention the methods you’ve used in the titles, write a story.

Do: Users tend to skip the payment step which leads to a 20% dropout.
Don’t do: I’ve run 20 quantitative usability tests to learn about user issues.

3. Results

Part three. Results highlight illustration

The resolution part. That’s where design managers learn if it was all worth it. There are 2 components to communicating your results:

1. Impact

2. Learnings

3.1 Impact

What were your key achievements? (e.g. Improved CVR by 10%).
Can you calculate the ROI? (e.g. This led to an additional $5k MRR).
If there are no measurable results, you can approximate testing results to the business impact. E.g. SUS correlates with NPS.
Alternatively, you can also mention the impact of this project on the company people or process improvements (E.g. I've implemented cross-functional discovery workshops).