A case study is proof with context

Case studies are one of the strongest forms of website content because they show that the business has solved real problems for real customers. But many project pages waste the opportunity. They show a screenshot or photo, add a vague sentence and stop there.

A good case study gives context. It explains who the client was, what problem needed solving, what constraints existed, what was delivered and why the result mattered. It helps future customers recognise themselves in the story.

The purpose is not to brag. It is to reduce uncertainty. Visitors want to know whether you understand their situation and whether you can deliver what you claim.

Choose the right projects

Not every project needs a full case study. Choose work that supports the kind of enquiries you want more of. If you want more healthcare projects, show healthcare work. If you want larger commercial projects, show evidence of that scale. If you want local service businesses, show clear examples from similar businesses.

Also consider variety. A portfolio with ten near-identical examples can feel repetitive. Select projects that show different sectors, challenges, services or outcomes.

If confidentiality is an issue, anonymised case studies can still work. Explain the sector, challenge and result without naming the client.

Start with the brief

Explain what the client needed. This should be more specific than “a new website”. Did they need better enquiries, clearer service pages, improved performance, easier editing, stronger SEO, a more professional first impression or support after launch?

The brief helps visitors understand the purpose of the work. It also positions the project as a business solution rather than a design exercise.

Use plain language. A future client should be able to say, “That sounds like our situation.”

Describe the challenge

Every project has constraints. The old site may have been slow, hard to edit, visually dated or unclear. The business may have had multiple audiences, complex services, limited imagery or a tight launch deadline.

Describing the challenge makes the case study more credible. Perfect projects with no obstacles feel less real. Showing how constraints were handled demonstrates judgement.

Be careful not to criticise the client. Frame challenges professionally and constructively.

Explain the approach

This is where you show thinking. What did you change and why? Did you restructure navigation, rewrite service pages, improve mobile journeys, optimise images, create a new visual system, set up hosting, migrate content or improve forms?

Avoid a long technical list unless the audience needs it. Connect decisions to benefits. For example, “We created individual service pages so visitors could find specific information and the site had stronger SEO foundations.”

The approach section is often what separates a useful case study from a gallery item.

Show the outcome

Outcomes can be quantitative or qualitative. Quantitative outcomes might include improved page speed, more enquiries, higher conversion rate or better search visibility. Qualitative outcomes might include clearer positioning, easier editing, stronger credibility or a smoother enquiry process.

If you do not have numbers, do not invent them. Explain the practical result honestly. A case study can still be strong without metrics if the work and benefit are clear.

When possible, include a testimonial from the client. Place it near the result so it reinforces the story.

Use images purposefully

Images should show the work clearly. For websites, include desktop and mobile screenshots where helpful. For physical projects, use high-quality before, during and after images. Avoid tiny thumbnails that cannot be inspected.

Captions can add value. Instead of leaving images unexplained, use captions to point out what changed: clearer navigation, stronger call to action, project gallery, booking journey or service comparison.

Optimise images so case studies do not make the site slow.

Include project facts

A short facts panel can help visitors scan:

  • Client or sector.
  • Services delivered.
  • Platform.
  • Project type.
  • Location.
  • Launch date.
  • Link to live site if appropriate.

Facts should support the story, not replace it. The narrative still matters.

Case studies should not sit isolated in a portfolio. Link them from relevant service pages, sector pages and articles. A visitor reading about website hosting may appreciate a case study showing a faster rebuild. A visitor reading about healthcare accessibility may need a relevant public-facing project.

Internal linking turns case studies into proof at the point of decision.

Keep case studies updated

A case study can become outdated if the client changes the site later, closes down or moves away from the original work. Review project pages periodically. If the live site no longer represents your work, consider using archived screenshots and explain the original project, or remove the link.

A strong portfolio is curated. It should show the kind of work you want to be known for now.

Questions to ask before writing

Before drafting a case study, interview the person who handled the project. Ask what the client originally wanted, what was unclear at the start, what decisions made the biggest difference and what the client cared about most. These details often reveal the real value of the work.

Useful questions include:

  • What problem made the client look for help?
  • What was not working before?
  • Which audiences did the project need to serve?
  • Were there technical, budget, deadline or content constraints?
  • Which decisions had the biggest impact?
  • What changed for the client after launch?
  • What would a similar future client need to know?

The answers do not all need to appear in the final page, but they help avoid shallow writing. A case study written from memory often focuses on what was delivered. A case study written from questions explains why the work mattered.

A case study template you can reuse

Use a repeatable structure so new case studies are easier to add:

  1. Project summary: one short paragraph explaining the client, project and result.
  2. Background: what the client does and why the project mattered.
  3. Challenge: what needed to improve.
  4. Approach: the important decisions and work completed.
  5. Result: the practical outcome.
  6. Services: a short list of what was delivered.
  7. Proof: testimonial, screenshots, photos or measurable improvement.
  8. Next step: link to the relevant service or contact route.

This structure keeps the page consistent without making every project sound identical. The difference should come from the details: the sector, challenge, decisions and result.

How much detail is enough

A short project note may be 300 to 500 words. A full case study may be 900 to 1,500 words. The right length depends on the value and complexity of the work. High-value or specialist projects deserve more explanation because future buyers need more reassurance.

Do not pad case studies with filler. Add useful detail: what was changed, why it was changed, what options were considered, what constraints existed and what the client gained. If the project involved SEO, content, hosting, accessibility or performance, explain those decisions in plain language.

The best case studies make the business easier to trust because they show judgement. They let visitors see the thinking behind the work, not just the final surface.

Where case studies should appear on the site

Do not rely on a portfolio page alone. Case studies should appear wherever they help someone make a decision. A homepage can feature a small selection of strong examples. A service page can include one or two relevant projects. An article can link to a case study that proves the advice in practice. A proposal or follow-up email can link to a case study that matches the prospect’s situation.

This matters because visitors do not all enter through the homepage. Someone may land on a service page from Google and never visit the portfolio. If the proof is not connected to the page they are reading, they may miss it.

Think of case studies as evidence blocks across the website, not only as a gallery.

What to avoid

Avoid publishing work that no longer represents the standard you want to sell. Avoid writing only about the design if the real value was strategy, clarity, performance or support. Avoid using project pages as dumping grounds for screenshots with no explanation.

Also avoid overclaiming. If you cannot prove a result, do not invent one. It is better to say “the new site gave the client a clearer structure and easier editing” than to imply revenue results you cannot verify.

Trust is built by specificity and honesty. A case study can be persuasive without pretending to be a miracle story.

Keep collecting proof

The easiest time to create a case study is immediately after a project ends. The decisions are fresh, the client is engaged and the assets are available. Add case study notes to the project close process. Capture screenshots, photos, testimonial requests and key outcomes before everyone moves on.

This habit makes the portfolio easier to maintain. Instead of trying to reconstruct old projects months later, the business gradually builds a library of proof that reflects current work.