A case study can be useful without a dramatic percentage in the heading. I want it to show what was difficult, what I contributed and what somebody can inspect. That tells a prospective client more than a confident result with no visible basis.
Concrete features and clear responsibilities make a useful starting point. Keep a distinction between a delivered feature and a measured business outcome, so the reader can judge exactly what the case study demonstrates.
Start with the problem somebody recognised
I write the opening in ordinary language. What was the team trying to do? What was getting in the way? A reader should understand the need before encountering the tools. A list of platforms is useful later, once the reason for using them is clear.
I keep the scope specific. If I improved one publishing workflow, I describe that workflow. I do not turn a narrow piece of work into a claim that I transformed the whole organisation. Clear boundaries make the contribution easier to trust.
Explain my part
I name the responsibilities I held and credit collaborators where appropriate. Design, implementation, project management and client liaison are different contributions. A case study becomes misleading if every sentence implies that one person performed all of them.
I include the decisions I can substantiate: why a simpler option was chosen, how an existing constraint shaped the design or what changed after a review. A screenshot of a finished page shows the outcome visually; a short explanation shows how I approached the problem.
Match each claim to evidence
For a delivered feature, I might show a public page, a documented example or a before-and-after view with permission. For an operational result, I need an appropriate record. For a commercial claim, I need measurements with context and a basis for attributing the change.
If I do not have those measurements, I say what I do know. The tool was built, the workflow supports a particular action, or the team approved the delivery. Those are legitimate facts. They should not quietly become claims about revenue, retention or time saved.
Keep examples readable
I choose a few images that answer different questions. One can establish the overall experience; another can explain a detail that mattered. Repeating five near-identical screenshots makes the page longer without adding much understanding.
Captions do real work. I explain what changed and where to look. If a screenshot is a prototype or an earlier version, I label it. If a public site has evolved since the work, I avoid implying that the current appearance is entirely my original design.
End with a useful boundary
I finish with what was delivered, what remains outside the scope and what kind of similar problem I can help with. This gives the reader a reason to get in touch without pretending that every project follows the same path.
A good case study is a small piece of evidence. It lets someone assess my judgement, understand my contribution and see how I communicate about real work. That is a stronger foundation for a conversation than a collection of impressive adjectives or an unsupported success story.
Choose wording your evidence can support
| What you have | A claim you can explain | What still needs evidence |
|---|---|---|
| A working published feature | “I built a way for editors to preview their changes.” | How often it is used, or how much time it saves. |
| A recorded task test | “The reviewer completed the agreed task during our test.” | Whether this applies to the wider audience. |
| A before-and-after report | “The measured figure changed over these periods.” | Whether the project caused that change and what else changed. |
| A visual concept | “This concept explores a possible direction.” | Approval, implementation or commercial results. |