How to write a portfolio case study: structure and a worked example

A case study is a short write-up of one project that explains what the problem was, what you did about it and what happened as a result. It turns a screenshot or a resume bullet into evidence a reader can actually judge.

This guide gives you a simple structure, walks through a complete worked example and covers what to do when the work is confidential or the result wasn't a clear win.

Why case studies matter

A list of projects tells a reader what you've worked on. A case study tells them how you think. That's usually what a hiring manager or client really wants to know: if they give you a problem, how will you approach it?

Case studies are useful in almost every field, not just design. Developers, analysts, marketers, project managers, teachers and operations staff all solve problems that can be explained this way. If you can tell the story of a piece of work clearly, you're showing communication skills at the same time.

The basic structure

Most good case studies follow the same four-part shape:

1. Problem: what was wrong, missing or needed, and why it mattered.
2. Role: who you were on the project and what you were responsible for.
3. Process: the key steps and decisions you made, including trade-offs.
4. Result: what changed, with evidence where you have it, and what you learned.

Add a title, a one-line summary and a visual, and you have a complete case study. The whole thing can be 300 to 800 words. Longer isn't better; clearer is.

Writing each part

Title and summary

The title should say what the project was in plain words. "Simplifying the clinic appointment booking flow" tells a reader far more than "Project Lighthouse."

Under it, write a one-sentence summary that someone could read on its own: "I redesigned a clinic's online booking flow so patients could book in fewer steps, which cut phone bookings noticeably over the following months."

Many visitors will read only this, so make it count.

Problem

Explain the situation before you arrived, as specifically as you can. Good problem statements answer:

• Who was affected?
• What was going wrong, or what opportunity was being missed?
• Why did it matter to the business, team or users?
• Were there constraints, such as time, budget, legacy systems or regulations?

Keep it to a short paragraph or two. The reader needs enough context to appreciate your decisions, not a full company history.

Role

Be precise about your part. If you were one of five people, say so, and say which pieces were yours. "I led the research and designed the new flow; a developer on the team built it, and our product manager handled rollout."

Overclaiming team work is easy to spot and damages trust. Being clear about your role makes your actual contribution more credible, not less.

Process

This is where most case studies either shine or fall flat. The weak version lists activities: "I did research, made wireframes, tested and iterated." Every case study says that. The strong version explains decisions.

Focus on two to four key moments:

• What did you find out that changed your direction?
• What options did you consider, and why did you choose one?
• What trade-off did you accept, and why?
• What went wrong, and how did you adjust?

Visuals help here: a before-and-after screenshot, a diagram, a chart or a photo of a whiteboard sketch.

Result

Say what changed. Use numbers where you honestly have them, and explain where they came from. If you don't have hard numbers, describe observable outcomes: fewer complaints, a process adopted by other teams, a client who came back for a second project.

Then add a sentence or two of reflection. What would you do differently? What did you learn? This is often the part interviewers ask about first. The guide on quantifying your achievements covers how to find and present numbers responsibly.

If you can't remember exact figures, say "roughly" or give a range, and only use numbers you could explain if someone asked how you measured them.

A worked example

Here's a complete case study for a hypothetical operations coordinator at a mid-sized charity. Notice how short each part is.

Title

Cutting volunteer no-shows at weekend food distribution

Summary

I redesigned how our charity confirmed volunteer shifts, which reduced last-minute gaps at our weekend food distributions and saved coordinators hours of phone calls each week.

Problem

Our food bank ran distributions every Saturday with around 30 volunteer slots. Volunteers signed up through an online form weeks ahead, but many forgot or had plans change. Most Saturdays, several people didn't arrive, and the coordinator spent Friday evening phoning through a list to fill gaps. Some distributions opened late or ran short-handed, which meant longer queues for the families we served.

My role

I was the operations coordinator. I owned the volunteer scheduling process and worked with our volunteer manager, who approved changes, and a part-time staff member who handled our email system.

Process

I started by looking at three months of sign-up records alongside who actually showed up. Two patterns stood out. People who signed up more than three weeks in advance were the most likely to miss shifts, and almost nobody cancelled ahead of time; they simply didn't come.

That suggested the problem wasn't commitment but memory and friction. Cancelling meant finding the coordinator's phone number, which most people didn't bother to do.

I considered requiring a deposit or limiting how far ahead people could book. Both risked putting off reliable volunteers, so I chose a lighter approach:

• An automatic reminder email five days before each shift, with a one-click "I can't make it" link.
• A second, shorter reminder the evening before.
• A standby list of volunteers who were happy to be called at short notice, automatically offered any slot that opened up.

We tested the reminders for four weeks before adding the standby list, so we could see the effect of each change separately.

Result

Over the following three months, unannounced no-shows dropped to around a third of what they had been. More importantly, cancellations now came in days ahead, and the standby list filled most of those gaps automatically. The coordinator's Friday phone calls went from a couple of hours to a few minutes, and distributions consistently opened on time.

Looking back, I'd involve volunteers earlier. A short survey would have revealed the cancellation problem faster than analyzing spreadsheets did.

That example is under 500 words, has no jargon and leaves the reader with a clear picture of how this person works.

Handling tricky situations

Confidential work

You can usually describe the problem, approach and type of result without naming the client or showing sensitive material. Swap the company name for a description ("a regional insurance provider"), use mock data in screenshots and round numbers. Never share anything covered by an agreement. If in doubt, ask your former employer or client what's acceptable.

Projects that didn't succeed

A project that failed can still make a strong case study if you're honest about it. Explain what you expected, what happened and what you learned. Showing that you can reflect on a setback is valuable. Just avoid blaming others.

Personal or practice projects

If you're early in your career, a self-initiated project works fine. Frame the problem honestly: "I wanted to learn how to build accessible forms, so I rebuilt my local library's event sign-up page as a practice project." See building a portfolio with no experience.

Common mistakes

1. Starting with your process before explaining the problem.
2. Listing every activity instead of explaining key decisions.
3. Being vague about your role in team projects.
4. Ending without a result or reflection.
5. Writing too much. If a section runs past a few paragraphs, cut it.
6. Using internal jargon or project code names a stranger won't understand.

Putting it together

A good case study follows a simple path: problem, role, process, result. Keep each part short and specific. Explain your decisions rather than listing activities, be honest about your role and give whatever evidence of the outcome you genuinely have. End with what you learned.

Start with your strongest project, write a rough version using the structure above, then cut it by a third. Put it first in your projects section. For more on where case studies fit, see what to include on a portfolio website and common portfolio mistakes.