A case study should help a reader understand a project, your part in it and the evidence behind the account. It does not need a dramatic success story. A precise description of a delivered output, a defensible decision or a lesson from a constraint can be more credible than an unsupported claim of transformation.
1. Give safe, useful context
Open with the type of project, the problem it addressed and the period covered. If the organisation or subject cannot be named, use an honest description such as “a small membership publisher” and state that identifying details have been withheld. Do not disguise a hypothetical exercise as commissioned work.
Template: Between [month/year] and [month/year], I worked on [project type] addressing [specific problem]. This account uses [anonymised/recreated/public] material because [brief reason].
2. Define role, scope and constraints
List the decisions and outputs you owned. Then record important boundaries: time, data quality, technical limitations, access, budget or the contribution of other people. This is not self-sabotage; it prevents a reader from attributing the whole project to one contributor.
- Owned: the tasks, decisions or deliverables directly handled.
- Contributed: work completed with others.
- Outside scope: adjacent work not performed or not evidenced.
- Constraints: facts that shaped the available choices.
3. Show the baseline and decision trail
Describe what was observable before the work began. This might be a test result, error pattern, content inventory or dated process note. Explain the options considered, the evidence available at the time and why one option was chosen. A decision log is especially helpful when hindsight makes an uncertain choice look obvious.
Link each important statement to an item in the proof-of-work evidence pack. Label extracts and recreations. If an artefact has since changed, record the date or version discussed.
4. Describe action in inspectable terms
Replace vague verbs such as “optimised” or “led” with observable actions. For example: “reviewed 42 pages against the agreed checklist, recorded 11 recurring defects, and rewrote the three templates responsible for seven of them.” The numbers must come from retained records, not memory dressed as measurement.
5. Report results with a method
If you have a measured result, state the metric, baseline, comparison period, collection method and date. Also note other changes that may have influenced it. A before-and-after pattern does not by itself prove that one action caused the change.
If no dependable result is available, say what was delivered or observed: a feature shipped, a review completed, an error reproduced, or a process documented. Avoid converting output into an outcome. “Published the new help flow” is supportable from a release record; “made every user successful” requires very different evidence.
6. Add limitations and reflection
Record missing data, unresolved questions and what you would test next. Explain one decision you would repeat and one you would change. This gives the case study an honest boundary and shows how the evidence affected your judgement.
Copy-and-fill outline
- Title: project type and specific task.
- Context: problem, period and disclosure status.
- Role: owned, shared and excluded work.
- Baseline: dated starting evidence.
- Decision: options, constraints and rationale.
- Action: inspectable steps and linked artefacts.
- Result: measured finding with method, or delivered output.
- Limitations: what the evidence cannot establish.
- Reflection: learning and next test.
A case study is evidence-led communication, not independent validation. For a reusable index across several projects, continue with the career evidence map.