Help Card: Writing a Case Study
We write case studies of the work we've done to illustrate the way we work, our approaches and to describe the great work we've done.
Use this guide when you're writing a case study the Convivio way.
What is a case study?
I'm thinking about writing a case study, but how do I choose what to write a case study about? Here’s some pointers to help you choose.
None of these are hard-and-fast rules, just guides to help work out what the case study should be about.
1. Try to focus on one client
Most readers will be potential clients themselves. They will want to identify with the client in the case study, finding similarities with that client’s situation and their own. In particular, by associating with the case study client’s journey, they should be able to recognise how we can help them make that from-here-to-there journey for themselves.
There may be times when it’s useful to talk about more than one client’s experience in a single case study, particularly when it’s helpful for illustrating our abilities. But that should be the exception.
2. Try to focus on the transformation
What has changed for the client in the case study?
Where were they at?
What was their initial context?
What problems did they have to begin with?
What problems did they not realise that they had?
Where did they get to at the end?
How did we overcome those problems?
What solutions did we find?
What differences did we make?
What did we learn along the way?
3. Keep the focus tight
Try to stay focussed on one particular, essential thing that we did for the client.
Don’t get sidetracked into writing long and sprawling essays. Short is good.
It may be helpful to outline other things also — other things we did, other things we learnt, other problems that were solved, etc. — but keep the focus clear and tight. It's likely that there will be more than one case study for each client project, probably several, so there's no need to cram everything into one.
Writing my case study
Once you know what you want to write about, use the help below to write your case study.
Start from the Template
There is a Google Doc template for writing a case study. Use this as your starting point — make a copy of it in the same folder, and name it appropriately for the case study you're writing, using the year-month-title file convention, something like …
2020-09-Cabinet-Office-Leadership-Alpha
The template has sections for the areas below.
01. The title
Some simple rules-of-thumb:
Use active voice
Emphasise the transformation
Emphasise the work done more than the client
Try to be specific, as much as possible
For example:
Transforming public services by connecting senior leaders
Succinct is good, but don't let it limit you.
02. The client
Almost all case studies are about one aspect of the work done for one client.
Name them.
However, sometimes the nature of the client organisation or something in the contract will mean we shouldn't name them directly. In this situation, try to give a broad outline of the kind of organisation they are.
03. Categorise the case study
We want our readers to understand at-a-glance if a given case study will help them get an insight into us and our work. A part of that is to categorise the case study.
We use several categories:
Agile phase
Our clients are all in public service, mostly in government, so we should use the common GOV.UK terminology for agile delivery.
Discovery
Alpha
Beta
Live
Retirement
By type of work involved
For example:
User research;
Service design;
Strategy;
Prototyping;
Content design;
Delivery management;
Engineering/development;
Devops;
Etc.
All of our work is in the public sector, so there’s no real need to use any market segmentation for categories.
04. The lede
Each case study should have a lede — a short sub-line or sentence that adds summary detail to the title.
We use two types of lead:
A subtitle
Think of what would appear after a colon in a long-form title.
E.g. the bit in bold here:
Transforming public sector leadership: building a new digital service to help senior leaders network, support and learn
One or two short sentences
I.e. a micro-paragraph
--
You may like to use one or the other, or both.
If you provide both then there is greater flexibility — either could be taken when the case study is used on the Convivio website (or elsewhere).
05. Overview
An introductory paragraph, or two tops, that summarises the case study.
This should be structured a bit like a pre-qualifying questionnaire (PQQ) 100-word answer:
what the situation was (the challenge, the goal)
the work the team did (the solution, what we did)
what the results were (the outcomes, what was learnt)
You may like to include bullet points to identify particularly important parts.
06. What we did
This section is a longer version of the overview. This should cover:
The situation/challenge/objectives
The work the team did, what the solution was, etc.
Some rules-of-thumb for this section:
Keep paragraphs short. For readability, try to stick to just a few sentences per paragraph.
Use subtitles for clarity. It helps to break the work down and increases readability/scannability, so a time-poor reader can understand exactly what we did.
Use bullet points to summarise objectives, sections, actions, milestones, etc.
Use images and screenshots for illustration.
Make use of quotes, where appropriate.
Covering two delivery phases?
A case study may, for example, include work done in both a Discovery and an Alpha.
If so:
Split this section into two, one for each phase
Use the same structure as above for each
The situation
The work the team did
07. Outcomes, results, etc.
This is a clear summary paragraph or two at the end of the case study.
Make good use of bullet points to summarise things. They make the specific results, outcomes and impacts clear and easy to identify.
08. Impacts, key deliverables, etc.
Use bullet points to list specific impacts and things that were delivered for the client to the service users. Focus on the ‘added value’, the benefit to service users.
These may be used elsewhere:
In particular design elements on the page
On the case studies landing page
09. Quotes
We should include quotes from clients and stakeholders, and, where possible, service users or other beneficiaries of the outcomes or work delivered.
10. Imagery and media
It is a good practice to use photos and images to illustrate the case study.
Here’s some rules-of-thumb for photos and images.
For photos, use action shots from the work being described with the actual clients if possible, .e.g.
in workshops
of tools used, like post-it walls, card sorts or ice boxes
Use images of the things produced, where appropriate
pencil sketches
wireframes
UI prototypes
final products
anything else in between
Try not to use stock photography — sometimes it’s unavoidable, but it can make the case study look false or fake.
Videos can be good, where appropriate
11. Call to action
We will always have a default call to action available.
But, if possible, it is better if there is a particular action we want readers to take at the end of the case study, one that is closely related to the content of the article.
Try to include something specific if possible.
For example, a case study focusing on accessibility might link to a downloadable guide on the subject for product owners, promote a forthcoming webinar, or include a contact form tailored to this issue.
12. Peer review
As with virtually all public-facing content, our case studies need to have a peer review. This is a time for colleagues to check what you've written.
Asking for a review
Ideally, you should ask for more than one person to review your case study
You should certainly ask for a review from at least one person who involved in the work in the case study, someone who knows what was done on the project or for the client and understands the work from personal experience. This review of what you've written should make sure its a fair representation of the work and the outcomes.
If possible, ask for a review a colleague who did not work on the project. This is to get a review from an 'outsider's perspective' on what you've said about the work and the outcomes.
Giving a review
When reviewing a case study there's two aspects to look at:
What's broadly called 'content editing' — evaluating the structure, the flow, the completeness and the overall quality of what's been written. This level of review shouldn't get too detailed with the actual words on the page, rarely looking at this stage below the paragraph level (though sometimes particular sentences may benefit from a 'content editing' feedback).
What's broadly called 'line editing' — here you're looking line by line, looking at sentence structure, confusing word order, clarity, that sort of thing, making sure that the piece reads in a 'Convivio voice'. You may also look at picking up errors — spelling mistakes and other typos, grammatical errors, tidying up punctuation, and so on.
Review feedback is vital, but do remember to be gentle as a reviewer. Feedback from a review can be painful, so try to be encouraging as much as possible.
13. Client sign-off
Once you've written your case study it will need to be cleared with the client (or clients) portrayed in the piece.
We need to be careful that case study does not betray and confidentialities, commercial or otherwise. And we need to the client feels happy that it does bring any risk to their reputation.
Ordinarily, you should ask the client's product owner for a review — usually, they have the best overview of the work — though they may pass it to someone else on their team for the review.
Last updated