If we liken a UX portfolio to a sandwich, then the case studies are the meat. Yes, you need to include a short bio, a list of courses you've attended and testimonials from happy clients. But what you'll be judged on is the work you've done in the past. And that work will almost always take the form of a case study.

Even if you're not one for a portfolio, you still need to create case studies. For example, if you're an external UX consultant, clients want to know about similar work you've carried out. Your client's RFP will contain a section where you need to describe your experience. And if you're part of an internal development team, you need to describe your work to your senior managers and co-workers (who may have little real understanding of UX). These descriptions of your work are case studies too and represent an opportunity to demonstrate the value of your work.

The storytelling approach

The best case studies help your audience tell your story. When your story resonates with your audience (for example, a short video clip that shows a customer struggling to checkout because of the organisation's penchant for jargon), you've scored a home run. A compelling story will travel through your organisation and amplify your impact.

If this is the first time you've created a story-based case study, a good place to start is to identify the stories you want your managers or co-workers to tell about the work that you do. Once you've identified these stories, look through your previous research studies for the material that will help people tell those stories. Which of these projects do you understand best from start to finish? Use that as your first case study.

Make the stories as simple as possible: like most good stories, there should be one key point. This matters because your reader may be too busy to really understand the detail of the work. You can put the entire report on your intranet — but you must write the 'press release' too. The case study is your press release.

Assembling the material for the case study

To collect the data for your story-based case study, we'll use an acronym: POWER.

The POWER acronym stands for:

• Project: What project was this? What was special or unusual about this project?
• Objective: What did you have to achieve? What was your role on the project?
• Work: What work did you do? Why did you do that rather than something else?
• End result: What did you achieve through the work? What were the outcomes?
• Reflection: What did you learn? What will you do differently next time?

Following this structure will automatically create a case study in a story format commonly referred to as the "Hero's Journey".

Let's dive into each of these sections in more depth.

Project

In this section of the case study you'll answer these kinds of question:

• What was the title of the project? Use an understandable version ('Digital Postcard' not 'Digicard')
• What was the history before you joined? Had they tried user research in the past and failed?
• What, if anything, had been done in the past to solve the problem?
• Were the team pro- or anti-user research?
• How many people were on the team?
• Was the team co-located or were some people working remotely? Were you co-located?
• Was the project 'political'? Was there interference from senior management?
• What was the development methodology? Agile, waterfall, something else?

In the context of a story, this is where we introduce the characters. Use these prompts to generate a maximum 100-word introduction to your case study.

Objectives

In this section of the case study you'll answer these questions:

• What was the specific reason you were brought onto this project?
• Why at that specific point and not earlier or later?
• What was the problem or opportunity?
• What were the effects on the team and the organisation? The actual ones of not solving the problem; the potential ones of not realising the opportunity.

In the context of a story, this is the trigger that starts us off. Try to generate 2-3 key objectives. List these as bullet points.

Work

In this section of the case study you'll provide a high-level summary of your approach, make the stages of the work explicit and state the reasons why, out of a universe of possible approaches, you chose this one.

Useful action words you can include here include: accomplished, administered, carried out, carried through, completed, concluded, delivered, enacted, executed, finished, fulfilled, managed, negotiated, obtained, operated, optimised, perfected, performed, procured, produced, reached, realised, resolved, solved.

In a story, this phase is known as the quest. Describe the work in a maximum of 100 words.

End result

In this section of the case study you'll describe the benefits that the team and organisation achieved as a result of your research work. Typically, there are three main kinds of benefit with the work we do as UX researchers: saving the organisation money; making the organisation money; and increasing use of the system. Here are some ideas that may help:

• Saving money: Reduce costs; save development costs; save development time; reduce maintenance costs; Call Centre deflection; save redesign costs
• Making money: Increase revenue; increase transactions; increase product sales; increase traffic/usage; retain customers; increase loyalty; attract more customers; increase market share
• Increasing use: Improve effectiveness; increase success rate; reduce user error; increase productivity; increase user satisfaction; increase job satisfaction; increase ease of use; increase ease of learning; increase trust in systems; decrease support costs; reduce training costs

Use these prompts to generate 2-3 bullet points describing the outcomes of the work. This is the resolution to your story.

Reflection

This final section is where you show that you are a reflective user researcher. It's very tempting to write a case study as a "Just So" story where everything went perfectly to plan and the results were outstanding. This never happens except on the most trivial of projects (and if it's a trivial project, it's not worth writing a case study about).

So this section of the case study should help the reader identify what you can do now that you couldn't do before you started that project. In the context of a story, this is where you — the hero — becomes a little wiser.

Questions to answer in this section of the case study include:

• What did you learn in the process of doing the work?
• How did you adapt or revise your initial approach?
• How did you move the team forward?
• What went well or badly?
• What would you do differently next time?

Use these prompts to generate a 100-word description of what you learnt and what you would do differently next time.

Reading over your case study

As you read over your case study, identify 1-2 images, illustrations or diagrams you could use for each section. You may end up using just one or two images in your case study but this step will give you several to choose from. Avoid trivial images (such as people stood at a whiteboard doing an affinity sort) and look for images that tell their own story without needing a caption.

In the text itself, search for every place you used the personal pronouns, "I" and "me". Ask yourself if it would be better to use "we" and "our". Design is a team sport: if you are using this case study in your portfolio, the reader will want to check you play nicely with others.

Finally, if you've followed my word count recommendations, your case study should be about 300 words plus a couple of bulleted lists. That's a challenging target, not because it's long but because it's short. The reason for aiming for brevity is that you want your case study to get read. Even with an image or two, this should still fit on a single sheet of A4 paper. Keep your sentences short, use the active voice and don't use a long word when a short one will do.