How to get case studies right
Every audit we run turns up some version of this. The short answer to case studies is that it is mostly a sequence of small decisions, not one big one.
Writing for the web is largely an editing job: the first draft is always longer than it needs to be. It rarely shows up as a line item, which is exactly why it slips.
What is actually at stake
Problem, approach, result, in that order. Where this goes wrong is almost never a lack of knowledge. Check it against what you would want a competitor's site to get wrong.
The steps
- Establish what you have today before changing anything
- Numbers make it credible
- Name the client if they will let you
- Write down the decision so the next person does not re-litigate it
Name the client if they will let you. The cost of getting this wrong is rarely visible on the day it happens. Check it against what you would want a competitor's site to get wrong.
Turning this into a decision
The short version
Content is the part of a project most likely to be underestimated and most likely to delay a launch. Three things worth confirming about case studies before you move on:
- Someone can say what the current setup is without going to look
- Name the client if they will let you — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Pick the one that would hurt most if it failed, and start there.