Case studies, explained without the jargon

We end up explaining this on discovery calls often enough that it deserved writing down. Here is case studies without the vocabulary that usually surrounds it.

Pages that answer a real question outlive pages written to fill a slot in a sitemap. Budget a little time for it every quarter and it never becomes a project of its own.

The short version

Problem, approach, result, in that order. Getting it slightly wrong is survivable. Ignoring it entirely is not. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. None of that requires a large budget, only a decision and someone to own it.

Numbers make it credible. The teams that handle this well are rarely the ones with the biggest budgets. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Turning this into a decision

Name the client if they will let you. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is the sort of thing that looks like polish right up until it costs you an enquiry.

The short version

Writing for the web is largely an editing job: the first draft is always longer than it needs to be. Three things worth confirming about case studies before you move on:

• Someone can say what the current setup is without going to look
• Numbers make it credible — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.