How to Write a Case Study That Wins Work

A prospect reading a case study is asking one question: have you solved a problem like mine? Most case studies answer a different one.

How to Write a Case Study That Wins Work — Troiana insight cover

In short

A case study should let a prospect recognise their own situation, then show that you resolved it. That means spending real space on the problem and the constraints, being specific about what you did and why, and stating outcomes with numbers. A portfolio of pretty screenshots proves you can design; a case study proves you can think, which is what people are actually buying.

What the reader is actually doing

Someone reading your case studies is not admiring your work. They are pattern-matching: is my problem in here?

If they recognise their situation in the first paragraph, they read on and arrive predisposed to talk. If they see a beautiful screenshot and a paragraph about a bold new visual identity, they learn that you can design, which they assumed, and nothing about whether you can help.

This is why the problem section matters more than the solution section, and why most case studies get the ratio backwards.

Lead with the problem, specifically

"The client wanted a fresh new look" describes nothing. Every client wants that.

What makes a reader recognise themselves is the specific constraint:

Six production lines under one roof was the selling point, but a brochure site flattened them into one vague list, and every enquiry arrived as "can you print something like this?"

A reader with a similar problem knows immediately this is relevant. That sentence does more selling than any visual.

So: name the business situation, the constraint, and what it was costing. If you cannot articulate the problem in two sentences a stranger would understand, you probably do not understand the project well enough to write about it.

Show the thinking, not the deliverables

The middle section should explain the decisions and, crucially, why — including what you rejected.

"We built the site around the brief rather than the brochure: a section per production line, a filterable catalogue, and a studio that composes artwork on a real print zone."

That is a decision with a rationale. Compare it with "we designed a modern, responsive website", which describes the category rather than the work.

Mentioning a path you considered and rejected is disproportionately persuasive, because it demonstrates judgement rather than execution — and judgement is what a client is uncertain about when hiring.

Results need numbers

This is where most case studies collapse into adjectives.

"The client was thrilled with the result" tells a prospect nothing. "It took 25 orders and 8 quote requests on its first day live" tells them something they can imagine happening to them.

Use whatever you genuinely have: orders, enquiries, load time, conversion rate, pages shipped, time saved, error rates. Even operational numbers work — seven routes shipped with zero console errors and 96.2% less image weight is specific and checkable.

Never invent them. A fabricated metric is the fastest way to lose a technically literate prospect, and results that cannot survive scrutiny are worse than no results — this is the same reason first-hand evidence is what earns citation as well as trust.

When the numbers are confidential

Common, and solvable.

Use relative figures. "Conversion up 34%" without absolute revenue is usually acceptable, and often more meaningful anyway.

Use your own operational numbers. Delivery time, pages shipped, performance improvements, defects at launch — these are yours to report.

Use a client quote. Less strong than data, but specific praise from a named person beats vague praise from nobody.

Ask. Clients frequently agree to figures being published when asked directly, particularly if they get to review the wording. Build the request into project close-out, when goodwill is highest and the work is fresh.

Length and structure

Long enough to establish the problem and the reasoning; short enough to be read. Most work at roughly 600 to 1,200 words.

A structure that holds up: the situation and constraint, what made it hard, what you did and why, what happened, and what you would tell someone facing the same thing.

That last section is optional and underused. It turns a case study into something useful to a reader who never hires you — which is exactly the kind of thing that gets shared and linked.

What to cut

Process theatre. "We began with a discovery workshop" — everyone says this, so it distinguishes nothing.

Team-size and timeline boasts, unless the timeline itself was the achievement.

Tool lists. Nobody hires a studio because it used a particular design tool.

Mockups on floating devices. They obscure the work and signal portfolio rather than evidence.

Vague superlatives. "Stunning", "seamless", "cutting-edge" are filler in every case study that contains them.

Making them findable

Case studies are among the strongest pages you have for search and for AI citation, because they contain original, specific, verifiable information that exists nowhere else.

Give each its own URL with a descriptive title naming the client and the problem type. Use the words a prospect would search — the industry, the type of work, the outcome. Link to relevant service pages. And keep them current, because a portfolio whose newest entry is three years old raises a question you would rather not raise.

If you have work you have never written up properly, that is usually the cheapest marketing available — book a call.

Common questions

What should a case study include?

The business situation and the specific constraint, what made it difficult, the decisions you made and why, and the outcome with real numbers. The problem section matters most, because a prospect is pattern-matching for their own situation rather than admiring the work.

How long should a case study be?

Usually 600 to 1,200 words — long enough to establish the problem and your reasoning, short enough to actually be read. Length is less important than the ratio: most case studies spend too much space on the solution and not enough on the problem that makes a reader recognise themselves.

What if the client won't let me share results?

Use relative figures rather than absolutes, since 'conversion up 34%' without revenue is usually permitted and often more meaningful. Use your own operational numbers — delivery time, performance improvements, defects at launch. And ask directly at project close-out, when goodwill is highest; clients agree more often than people expect.

Should case studies include metrics?

Yes, and never invented ones. Specific numbers are what let a prospect imagine the same outcome for themselves, while adjectives like 'thrilled' and 'stunning' tell them nothing. A fabricated metric is also the fastest way to lose a technically literate prospect.

Do case studies help with SEO?

They are among your strongest pages for both search and AI citation, because they contain original, specific information that exists nowhere else. Give each its own URL, use the words a prospect would actually search — industry, type of work, outcome — and keep the set current.

Have something worth building right?