How to turn one useful project into a credible case study
Document context, work, and limits using facts your client or records can support.
On this page
A credible case study lets a prospective client understand a piece of work without asking them to take your word for a larger story. It names the setting, the work, and the evidence you have permission to share. It also states the limits of that evidence.
Start with a project that produced a decision, a deliverable, or a change you can describe accurately. You do not need a dramatic number. A well-scoped account of what happened can be more useful than a result claim that nobody can inspect.
Get permission before you draft
Decide who can approve the material before you collect screenshots, quotes, or project details. That may be the client, an employer, a project owner, or a communications contact. A public logo on a website does not automatically give you permission to name the organisation, describe the work, or reuse a statement from a client.
Send a short written request that includes:
- the proposed title and one-paragraph summary
- the client or project name you want to use, if any
- the facts, images, and quotation you plan to include
- where the case study will appear
- who can approve the final version and by when
Keep the reply with the project record. Approval can be narrow. A client may approve a description of the process but not internal numbers, screenshots, staff names, or a testimonial. Record that boundary in the draft instead of trying to remember it later.
If you cannot get permission, write about a public method or a general problem only if doing so does not reveal the client through dates, distinctive facts, or surrounding details. Do not turn a confidential project into a disguised case study.
State the starting context
Readers need enough context to judge whether the work resembles their situation. Give them the type of organisation, the decision or problem, the relevant constraints, and your role. Leave out details that identify a client when they are not approved.
Use sentences that name what you know. This example is illustrative:
A regional membership organisation asked our team to map how new members moved from their first event to a renewal decision. I ran interviews, reviewed the existing journey, and prepared a prioritised set of changes for the internal team.
It tells the reader the setting and contribution without claiming an unverified outcome.
Avoid opening with labels such as “transformational engagement” or “industry-leading results.” They make the reader work harder to find the actual work. A reader can assess a case study when it answers four ordinary questions:
| Question | Useful detail |
|---|---|
| What was happening? | The decision, problem, or service under review |
| What constraints mattered? | Time, scope, existing systems, approvals, or audience |
| What did you do? | Your specific role, method, and deliverables |
| What can the reader verify? | An approved public page, quotation, artefact, or carefully scoped observation |
Dates can matter. “In a 2025 project” is different from presenting an old process as current. Add a date when it helps a reader place the work, and do not imply an ongoing relationship after it ended.
Describe the work in a sequence a reader can follow
Write down your contribution before writing about the result. A clear case study usually follows the order of the work: understand the situation, make decisions, do the work, and hand over or measure what the project owner agreed to measure.
For each step, name the material you used and the decision it informed. “Reviewed support requests and interview notes, then grouped recurring problems before the workshop” tells the reader more than “created a customer-centred strategy.”
Be careful with team credit. If you coordinated research, say that. If several people designed the service, name your part instead of assigning the full project to yourself. The distinction protects colleagues and makes your account easier to trust.
| Vague claim | More supportable wording |
|---|---|
| “We fixed onboarding.” | “We mapped the existing onboarding flow and supplied a prioritised change list for the product team.” |
| “I delivered a successful launch.” | “I prepared the launch content and reviewed the support material with the client team.” |
| “Our research proved the answer.” | “The interviews identified recurring concerns that the team used in its next planning session.” |
The second column may sound less dramatic, but it gives a buyer a realistic picture of what they could hire you to do.
Show approved evidence and name its limits
Evidence should sit close to the claim it supports. An approved client quotation can support the experience described in that quotation. A public project page can support a project name, date, or contribution where it identifies those facts. A private spreadsheet does not become public proof because you refer to it in broad terms.
If you report a result, identify who measured it, what period it covers, and what the result does and does not establish. Do not shorten a team result into a personal credential. Do not turn a reported change into a guarantee for the next client.
Google's people-first guidance is a useful editorial reference for clear authorship and helpful material, not a promise of ranking, citation, or recommendation. Google's guidance
Use a final claim check before publication:
| Item | Check |
|---|---|
| Client and project name | Approved for this use |
| Your role | Matches the project record and team account |
| Quotation | Exact wording approved by the speaker or authorised reviewer |
| Result | Public or specifically approved, with measurement context |
| Link or image | Opens to the approved public material |
| End date | Does not imply a current relationship if the project ended |
Add the approval, source URL, reviewer, and review date to your source consistency checklist. Then read the draft as a buyer would: can they tell what you did, what evidence they can inspect, and what remains private?