The Art of Storytelling for Case Studies

I love a good story. The anticipation. The buildup of conflict. The climax and the payoff. As you experience the journey through the hero’s eyes, you might be left laughing, crying, or nodding your head in agreement. Stories are a vibrant way to share our life experiences.

Stories can be hard to tell when you’re writing about your work, though. Chatting with coworkers or venting to your partner in choppy anecdotes after a long day might feel easy. It’s much harder to tell a polished story when you’re looking for that next big opportunity or sharing it with an audience of your peers in a formal presentation. 

That’s right, I’m talking about case studies.

Many people don’t connect writing a case study with writing a story. The words sound so dry and clinical in comparison to the warm embrace of story. A case study is decidedly not cozy, and the subject matter is usually dry. It screams, “Take me seriously!”

But I’m a believer in looking at a case study like a story, especially when it comes to UX disciplines. A good story needs a plot, characters, and a conflict (user pain-points, anyone?) It also requires a beginning, a middle, and an end. When the storyteller leaves these things out, it’s harder for the reader (the hiring manager) to follow along. It’s difficult to understand where the project started, why it happened in the first place, and what the outcome was.

I’m no expert at this, nor am I a career advisor, so there’s no guarantee this advice will get you a job interview or offer. But I find a lot of joy in writing case studies and helping others write theirs. The basic structure of UX design, UX writing and content strategy, and UX research case studies have important elements in common and all follow the same general path. 

I’ll share some of the ways I lead the audience through a journey while highlighting all that I accomplished along the way.

Structuring a Case Study

In the past, I found reviewing, outlining, and writing case studies to be intimidating and exhausting. So I came up with a process to carefully craft a case study, make it less painful, and reach the same goal. I start by outlining three main points:

1. The background
2. The process
3. The outcome

The Background

The story needs to start somewhere. Introducing the main characters and the plot helps set the stage for the reader and gives them a reason to care. In the initial phases of writing a case study, I like to answer these questions:

• Who was this project for?
  • If it was your company, take a sentence or two to explain the business or the product team you were working with.
  • If it was a freelance project, talk about why you were approached with the project.
• What problem existed and for whom?
  • Who was the target-user? What pain points did they face? Why was this a problem? How did it specifically impact the users?
• What was your role in solving that problem?
  • What is the elevator-pitch summary of your contribution to this project? Were you on a team with multidisciplinary partners? Or part of a tiny multiple-hat wearing startup? You’ll be going into depth about how you solved the problem later on, so give just a teaser.

Often, my first draft isn’t made of concrete paragraphs. I simply get the information out of my brain and into a document. In early stages of writing, these questions help me frame the problem in a way that clearly highlights my contributions to the solution. 

The Process

This is where you’ll spend the most time crafting your story. Whether you’re writing a case study to share as a presentation or adding it to your portfolio, the audience is most interested in how you got to the outcome and which parts of the process were your responsibility. I list out the most important pieces by answering these questions:

• What happened to kick off this project?
  • Did you have to do research? Was there a competitive analysis or heuristic evaluation involved? What data put this into motion, and what did you do with it? What steps did you take to educate yourself about the problem and the users?
• What steps were taken to move toward the solution?
  • Which parts of the process were done solo, and which were done in collaboration with cross-functional partners? When were the stakeholders involved? How many iterations did it take to make it to the solution? Did you run brainstorming sessions or design studios along the way? Was there A/B or usability testing done in tandem? Write down as many steps as you can remember. You can edit later.
• What were the deliverables along the way?
  • The audience is always interested in what’s behind the curtain. What design deliverables can you share? Low-fidelity wireframes, prototypes, rough drafts of scripts, process maps, personas? Help the audience understand how you think. Nothing goes from A to Z without a mess in the middle. We’ve all seen enough squiggly line graphs to know that design is not a pretty process.

The Outcome

The outcome section is the grand finale of your case study. It explains why the project kicked off in the first place, what happened after, what next steps the team took, and what you learned.

Not every case study needs a happy ending. I’ve worked for months on a project, only to hear “shut it down!” in the end. This doesn’t mean the work is useless or that you can’t include it in your portfolio.  We learn most from our failures, and openly sharing those shows we’re constantly trying to improve our process and understand the market better. Regardless of how the project resolved, a good outcome section answers questions like:

• What was the solution?
  • This is a great place to show off the shiny final designs. After the climax comes the triumphant ending where the heroes (you and your team) can celebrate a job well done. This is what everything has been building toward: the resolution of conflict, whether it’s triumphant or tragic.
• What were the quantifiable results?
  • Here, it’s easy to show off metrics that improved as a result of your work. Tangible quantitative results make a strong conclusion to any story, but they aren’t necessary if they don’t exist. You can reframe to express impact in a variety of ways.
• What non-quantitative impact did your work have on the whole project?
  • Describe the next steps your team took or planned. Did you change a broken flow or process that the team ended up adopting? Did this project lead to another initiative? Or did it result in a post-mortem retrospective full of learnings that the team can use  in the future? Your work added value even if the CEO ended the initiative or a project manager shut it down after a few months of zero traffic. A good story can define what positive impact means in the face of a troublesome ending.
• What did the team learn from the experience?
  • If it was a success, what did you learn about the market, the user,  and the approach you took? If it was a failure, how did the team learn from the experience and move forward after the dust settled? 

Polishing up the Outline

Once you list every step of the project, you’re more than 50% done with crafting your case study.  The hard part—getting started and remembering everything—is over. Now it’s time for you to turn these boring bullet points into elegant paragraphs of UX genius.

The Beginning

You’ve identified the details, now it’s time to build a narrative. We often meet a protagonist first, but who are they? What is their purpose? First impressions matter, and your audience will want a reason to care about what they’re reading. The beginning of any case study sets the reader up for everything that follows. 

To make a good first impression, I usually leverage a dynamic medium, like Google Slides. I keep text minimal and limit the number of slides and images. The hiring manager reviewing your work doesn’t have the time to get familiar with every detail of your case study. Be clear and concise, split the background slide into two to three distinct paragraphs. Remember, if you get the interview, you’ll have time to go into more detail.

• Paragraph one: Introduce the team or business who enlisted you to solve the problem, what the problem was, and where it originated.
• Paragraph two: Lay out the primary goal for the project, the solution you hoped to reach, and summarize your contributions.

A limited number of well-selected visuals throughout a slide-deck portfolio can give readers a more concrete image of the story. If you’re building a story for your website, you can be more liberal with imagery since space isn’t a concern. An engaging visual will represent the project, add some visual interest, and give context for the rest of the case study.

The Middle

This is where the hero sets out, looking for purpose. They will encounter perils along the way, meet new allies, and eventually fight that gold-hoarding dragon during the climax! But how long should it be, and what’s an effective way to present the content?

The middle section can vary greatly in length. I’ve written case studies where it only takes a few slides to summarize the journey. Others take many more. Stay focused and represent the events in chronological order. 

Another helpful tip for organizing an accurate story: don’t let the visuals do too much of the talking. In plenty of case studies, I’ve had to sift through dozens of wireframes, user flows, site maps, mock ups, branding style guides—with very little telling me what I’m actually looking at and why. It can be difficult to self-edit when you want to prove your skills to a hiring manager. The hard truth is, showing one user flow is enough to prove that you know how to make a user flow. It’s more important to demonstrate that you understand why you created that user flow, what purpose it served in the design process, and how you used it to communicate your intent to the other members of your team.

I like to separate the middle section of my case studies with numbered points. Each point can define one piece of the project, and I can use the same number to label a single example image representing that piece.

Bonus tip: Another part of telling an accurate story is acknowledging everyone’s work. Since you’re writing from your own perspective, it’s easy to use “I” and accidentally take undue credit. If you were part of a team, use “we” instead of “I.” It won’t weaken your case study just because you can’t claim to exclusively own every part of the process. Hiring managers want to know you can work as part of a team and not just on your own.

The End

We have reached the end of our story. Did the hero triumph over the dragon and return to their village with riches galore? Or were they sadly and tragically swallowed up, only to be memorialized for all eternity in epic ballads by their friends and family? The end of a case study, whether the project was successful or not, is a celebration of your accomplishments. 

Some heroes finish their tales quantitatively; they can explain that each step in the process was a factor in X metric improving by X%, bringing in X amount of additional users, increasing conversions, revenue, KPIs. And so on. 

For other heroes, the impact isn’t as clearly quantifiable. The outcome of their story might be a jam-packed product roadmap, or the launch of an MVP, a successful handoff to a client, or the improvement of an internal company process. Don’t fret! You’ve still accomplished something. This is a great place to share a visual of the final product, a colorful product roadmap, a graph, or something similar.

Sadly, for the heroes that never return home, the ending (or outcomes section) might be more introspective. When my past case studies have ended in less-than-ideal scenarios, I’d quickly explain the circumstances that befell the project—noting any wrap-up activities I performed on my own or with the team—then focus on my learnings. 

Ending with what you learned is a solid alternative to showing impact. Personal and team growth deserve to be acknowledged and documented, even if you aren’t writing a case study. Recognizing what went well, why, and how you accomplished it will only make the next endeavor better. Especially when we fail, we learn what not to do. By ending your hard-earned story with a summary of what you learned, you’re proving to your peers or a hiring manager that you’re fully engaged in the process and the goals.

Conclusion

Humans are naturally drawn to storytelling. It’s a chance to provide the audience with a new and different way to think about a concept. A well-crafted story encourages the imagination to anticipate the arc of what’s next, like a moving picture in the mind.

Case studies can and should be just as enjoyable. While not as whimsical or fantastical as a hero’s journey, they provide value: lessons learned, mistakes made, and triumphs won. As UX professionals, we’re constantly telling the user’s story to our teams and stakeholders and finding ways to foster empathy with the user and their needs. Why don’t we craft our case studies as stories to evoke equally empathic responses? A glorious journey will always be more compelling than a clinical list of events.