Every B2B company has a case studies page. Almost nobody finishes reading one.
The analytics tell a consistent story across industries: visitors land on the case study, scroll a portion of the way down, and leave. They rarely reach the results section, which is the part the company considered most important. They almost never read a second case study. The page exists because the category expects it to exist, gets built once, and then underperforms quietly while everyone assumes it's doing something.
The reason isn't that people don't care about evidence. Buyers care enormously about evidence — a B2B purchase is a risk decision, and evidence that someone else took the same risk successfully is exactly what reduces it. The reason is that the standard case study format doesn't contain the evidence buyers are looking for. It contains a different thing, formatted persuasively, aimed at a reader who doesn't exist.
The Format Everyone Uses and Why It Fails
The near-universal structure is Challenge, Solution, Results. It's logical, it's easy to write, and it fails for a specific reason: it's organized around the vendor's process rather than the reader's question.
The Challenge section is usually a generic statement of a category-level problem. "The client's website no longer reflected their brand and wasn't converting visitors effectively." This describes roughly every company that has ever hired a design studio. It gives the reader nothing to recognize themselves in, and recognition is the entire mechanism by which case studies work.
The Solution section is typically a list of deliverables. "We conducted a discovery workshop, developed a new brand identity, designed a responsive website, and built it in Webflow." This is a description of a scope of work. It tells the reader what was produced and nothing about why those things rather than other things, which is the part that would demonstrate judgment.
The Results section is a set of percentages. "Conversion rate up 40%. Bounce rate down 25%. Time on page up 60%." These numbers are intended to be the payload of the entire piece, and they are the least believable part of it — for reasons worth examining closely.
The whole structure describes a project from the perspective of the person who ran it. The reader isn't interested in that. The reader has one question, and the format never answers it directly.
The Only Question the Reader Has
A person reading a case study is asking: is this me, and will that happen to me?
Everything else is secondary. They're scanning for their own situation — their size, their industry, their specific problem, their constraints — and trying to work out whether the outcome described is one they could plausibly expect. If they can't locate themselves in the story, the story is about someone else and there's no reason to keep reading.
This is why generic challenge statements are so damaging. A reader whose actual problem is "our sales team keeps losing enterprise deals at the security review stage" cannot map themselves onto "the client needed a more modern web presence." The specific problem is what creates recognition. The generic version, written to be broadly applicable, is applicable to nobody.
The counterintuitive implication is that specificity increases relevance rather than narrowing it. A case study that names an exact situation — a company of a certain size, in a certain market, with a certain particular failure — is more persuasive to readers who share that situation and no less persuasive to those who don't, because those readers were never going to convert on a vague story either. Trying to write one case study that speaks to everyone produces one that speaks to no one.
Why Nobody Believes the Numbers
The results section is where credibility is usually lost rather than established, and the mechanism is straightforward: unbaselined percentages are unfalsifiable.
"Increased conversions by 40%" raises immediate questions that the case study never answers. From what starting point? A 40% improvement on a 0.5% conversion rate is a different achievement than on a 4% rate. Measured over what period? Against what seasonal baseline? And attributed how — was the site the only thing that changed, or did the company also start running ads, hire salespeople, and launch a new product in the same quarter?
Experienced buyers know these questions are unanswerable from the outside, which means they discount the numbers reflexively. The percentages don't read as evidence; they read as marketing, and their presence slightly reduces the credibility of everything around them.
The counterintuitive fix is to claim less and explain more. A case study that gives a smaller number with a real baseline, states the measurement period, and openly notes what else was happening at the time is dramatically more credible than one claiming a larger number with no context. Acknowledging the limits of attribution — "the redesign shipped in the same quarter as a pricing change, so these figures reflect both" — signals honesty, and honesty about a modest result is more persuasive than confidence about an implausible one.
Where numbers genuinely aren't available or attributable, saying so is better than inventing something. Plenty of good work produces outcomes that can't be cleanly measured, and a case study that describes what changed qualitatively, specifically, and honestly is more useful than one that reaches for a percentage it can't support.
The Content That's Actually Missing
The most important thing absent from nearly every case study is the reasoning.
A buyer evaluating a studio is not primarily buying the studio's past output. They're buying its future judgment — the decisions it will make on their project, under uncertainty, with incomplete information. The past project is only useful as evidence of how those decisions get made.
Which means the interesting content is exactly what the standard format omits: what was considered and rejected, and why. What the hard trade-off was. What constraint made the obvious approach impossible. What the team got wrong the first time and how they figured it out. What the client wanted that the studio pushed back on, and what happened.
This content does two things simultaneously. It demonstrates thinking, which is the thing actually being sold. And it makes the story credible, because it sounds like a real project. A case study in which everything went smoothly, the client loved every concept, and the results exceeded expectations reads as fiction to anyone who has ever run a project — which includes everyone who might hire you.
Including friction feels risky. It reads as admitting imperfection. In practice it's the strongest available credibility signal, because it's the part competitors won't include, and because a reader who recognizes real project dynamics in your account trusts the rest of your account more.
Nobody Is Reading Two Thousand Words About Someone Else's Project
Even a well-written case study is competing against low intrinsic interest. The reader cares about their own problem, not about a stranger's project, and their engagement budget is small.
This argues for a layered structure rather than a long linear one. The top of the page should carry the entire argument in a form that can be absorbed in fifteen seconds: who the client was, what specific situation they were in, what was done, and what changed. If the reader stops there — and most will — they should already have the information needed to decide whether to contact you.
Below that, depth is available for the minority who want it: the reasoning, the alternatives, the process, the detail. This audience is small but high-intent, usually someone who has already decided you're a candidate and is now building a case internally.
The common failure is inverting this — burying the substance beneath a long narrative build-up, so that readers who leave early leave with nothing. The results section at the bottom of a two-thousand-word page is read by almost no one.
The Images Are Doing Less Than You Think
Most case study imagery is a sequence of full-page mockups floating on devices, arranged attractively, sometimes with a subtle drop shadow and a gradient background.
These images communicate one thing: the output looked professional. That's worth communicating, but it's a low bar and every competitor clears it. What the images don't show is what any of it does — which decision is visible in that screen, why that layout rather than another, what problem that component solves.
Imagery that supports the argument looks different. A before-and-after of the specific element that changed, cropped closely enough to actually see it. A detail shot of the component where the key decision lives, with a caption explaining the decision. A sequence showing a flow that was reduced from five steps to two. These are less beautiful as page decoration and considerably more persuasive as evidence.
The floating-mockup treatment isn't wrong. It's just doing brand work rather than argument work, and most case study pages consist almost entirely of brand work while the argument is left to text nobody reaches.
Design It for Forwarding
The reader of a case study is frequently not the decision maker. They're the person building a shortlist, gathering options, and preparing to justify a recommendation to someone above them.
That changes what the page needs to support. It needs to be quotable — containing a paragraph or two that can be pasted into an internal email and still make sense out of context. It needs a clear, specific summary of what happened that a non-expert can repeat accurately to a colleague. It needs to be scannable by someone who will skim it in a meeting on someone else's screen.
Most case studies are written as a continuous narrative that loses its meaning when fragmented, and a page that can't be excerpted can't travel through an organization. The recommendation dies with the person who read it, because they have nothing to hand upward except a link and an opinion.
What to Do Instead
The structural changes that follow from all of this are straightforward.
Lead with the specific situation, named precisely enough that the right reader recognizes themselves and the wrong reader self-selects out. Replace the generic challenge statement with the actual problem, in the terms the client would have used.
State the results early, honestly, with baselines and caveats. Claim less than you could and explain more than you normally would. Where attribution is uncertain, say so.
Spend the body on decisions rather than deliverables. What was the hard call, what were the options, why this one. Include at least one thing that didn't go smoothly.
Use imagery that shows the specific decision rather than the general polish. Crop in. Caption things.
Keep the whole argument accessible in the first screen, with depth available below for the small number of readers who want it.
And write it for someone who will forward a paragraph of it to their boss.
What a Case Study Is For
The purpose of a case study is not to prove that you did good work. Everyone claims that, and the claim carries almost no information.
Its purpose is to let a stranger predict what working with you would be like — how you think, what you'd do when something got difficult, whether you'd tell them the truth about a result, and whether your judgment is the kind they'd want applied to their own problem. A case study that demonstrates those things while describing a modest project outperforms one that asserts a spectacular outcome without revealing any reasoning behind it.
That's a different piece of writing than the one most companies publish. It's also considerably more interesting to read, which is the first requirement for a page that currently nobody finishes.