How to Create a Case Study for a Client Project

The project has shipped. The invoice is paid. Somewhere in a folder marked final_FINAL there are forty files nobody will open again — and in your portfolio, a gap where the work should be.

A case study isn't a summary of what you did. It's an argument for why someone should hire you to do it again, and that distinction changes what you keep, what you cut and how long the piece needs to be. Most good ones are shorter than you think.

Think of it as a sales document disguised as a story. The reader is not your mum, your old art director, or a competitor. The reader is a busy person with a similar problem, wondering whether you are the safe pair of hands. Every paragraph should either deepen the problem, prove the thinking, or show the result.

Lead with the problem, not the process

The instinct is to open with yourself: the studio, the intro call, the moodboard. Resist it. Open with the client's situation, written so a stranger understands why it mattered.

Weak: "We were approached by a Midlands joinery firm to refresh their brand."

Better: "A joinery firm with thirty years of commissions and a website built in 2011 was losing work to cheaper competitors who simply looked more current."

The second version gives the reader something to hold: a business, a problem, a reason the work had to happen. Two or three sentences is plenty. Go longer and you're padding the setup to make the payoff feel bigger than it was.

A useful test: cover your client's name and read the first paragraph again. If it could describe any project you've ever done, it isn't specific enough. Add the detail that makes it theirs — the deadline, the old system, the competitor, the internal disagreement, the thing the client actually said on the first call.

“The reader should finish the first paragraph knowing exactly what was at stake — and wanting to know what you did about it.”

Gather the evidence while the project is still warm

By the time you sit down to write, the useful detail has usually evaporated. Collect it as you go, or in one sweep the week after launch:

The original brief, plus your first reply to it. That reply often contains the sharpest thinking you did all project.
Kick-off notes and photographs. Half-formed ideas count, as long as they show how you got there.
Early versions: sketches, wireframes, rejected routes. Process images persuade more than another polished mockup.
Numbers the client is willing to share — enquiries, conversion, footfall, hours saved, stock sold.
The client's own words, lifted from emails or calls.
Permissions: what you're allowed to show, and whether you can name them.

The most useful habit here is a short email sent a fortnight after launch, asking three questions. Why did you choose us? What changed once the work went live? What would you tell someone considering a similar project? The answers become your pull quotes and most of your outcome section. Ask then, not in six months, when the detail has gone.

Keep a simple evidence log as the project runs. It can be a note, a spreadsheet, or a folder with dated subfolders. The format doesn't matter; the discipline does. When you're writing later, you'll want to know which decision was yours, which was the client's, and which happened by accident — because a case study is more convincing when it's honest about the messy parts.

One more thing: save the moment the client said yes. Not the signed contract, but the sentence in the meeting or email where they agreed to the direction. That's often the real turning point, and it's easy to forget.

Build a spine in four beats

Case studies fall flat when they're chronological. Nobody needs week four. Give the piece a spine: four beats that carry the reader from problem to proof. You can use headings for each, or write them as clear paragraph blocks, but the order should stay the same.

1. The situation

State the client, the context, and the problem in plain language. Include the constraint that made it difficult: a small budget, a regulated industry, a sceptical board, a launch date that couldn't move. Constraints create tension, and tension keeps people reading.

2. The insight

Show the moment you understood something the client didn't. It might be research, a customer interview, a competitor gap, or a simple reframing of the brief. This is where you demonstrate thinking, not software skills. A good insight can often be written in one sentence: “The problem wasn't that people couldn't find the showroom; it was that they didn't believe the work was worth the trip.”

3. The work

Describe what you made and why, but keep it selective. Choose three or four decisions that mattered. Pair each one with a visual or a short quote. Avoid a gallery of every screen; a case study is not an archive. If a detail doesn't help the reader understand the outcome, cut it.

4. The result

End with what changed. Use numbers if you have them, client quotes if you don't, and a clear statement of what the work achieved. Tie the result back to the original problem so the story closes. If the project is still too new for metrics, say what happened next: more enquiries, a smoother sales conversation, a team that finally agreed on a direction.

Make the result specific and believable

“Increased engagement” is not a result. It's a shrug. Specific outcomes give the reader something to compare against their own situation, and they make the whole case study feel less like marketing.

Weak: “The new site performed well.”

Better: “Online enquiries rose from 12 to 31 a month in the first quarter, and the sales team stopped sending PDF brochures because the site finally answered the obvious questions.”

If you don't have hard numbers, use the next best evidence:

A direct client quote about time saved, confidence gained, or a decision made easier.
A before-and-after comparison the reader can see: old process vs new, old message vs new.
A qualitative signal, clearly labelled: “The client reported fewer repeat questions from new customers.”
A follow-on project, referral, or repeat order — proof that the work was worth paying for twice.

Be careful not to overclaim. If the client's sales rose after a seasonal campaign you didn't run, say so. A believable result with a caveat is more persuasive than a suspiciously perfect number.

Handle confidentiality without gutting the story

Not every client will let you name them, show the work, or publish numbers. That doesn't mean the project can't become a case study. It means you need a plan before you write.

Ask early, ideally before the project starts, what you can share and when. Put it in the contract if you can. If the client says no to naming, offer an anonymised version: “a family-run joinery firm in the Midlands” or “a B2B software company with 40 staff.” You can still describe the problem, the thinking, and the outcome. You just remove the identifying details.

If you can't show final visuals, show abstracted ones: crops, diagrams, wireframes, or your process. If you can't share metrics, use ranges or percentages rather than exact figures, and label them clearly. And if the client is nervous, show them the draft before it goes live. Most objections are about surprise, not secrecy.

“A case study with one redacted detail is better than no case study at all — as long as the reader still understands the problem and the result.”

Edit for the skimmer, then publish

Most people will not read your case study top to bottom. They'll scan the headline, the first paragraph, the images, and the result. Write for them first, then reward the close reader with detail.

A quick final pass:

Does the first sentence name a problem a stranger can understand?
Can you cut the first paragraph without losing anything? If so, cut it.
Is there one clear insight, or are you hiding it among tasks?
Does the outcome connect back to the original problem?
Would a busy prospect know whether this is relevant to them in ten seconds?

Then publish it where people will actually find it: your portfolio, your proposal deck, your email signature, your LinkedIn. A case study that lives only on your hard drive is just another file in the folder marked final_FINAL. The point is to make the next project easier to win — and that means getting the story out while it still has heat.

Photo: kaboompics / Pixabay