How to Write a Website Case Study Buyers Can Verify

Choose one project and one decision to explain

A case study becomes easier to understand when it follows a specific problem. “We built a modern website” does not explain much. “The catalogue was difficult to navigate on a phone, so we organised products by application and added a consistent specification table” gives the reader a decision they can examine.

Before writing, establish who owns the project materials and what may be published. Collect approved screenshots, the relevant brief, your contribution and any available verification records. If client information cannot be shared, use a permitted description with enough context to remain accurate. Do not invent a client name or imply approval that has not been obtained.

Build the story around evidence you already have

The worksheet below separates the project story from the material supporting it. An empty evidence field is a useful signal: either gather the information or narrow the claim. It is not an invitation to fill the gap with a plausible number.

Make a before-and-after comparison fair

Choose comparable views: the same page purpose, a similar viewport and enough surrounding information to understand the change. A cropped image of the old site beside a polished mockup of the new one may look persuasive while revealing little about the actual experience.

Add captions that explain the change in plain language. A useful caption might identify a specification table, a clearer product grouping or an error message that now helps someone correct an entry. If you show a prototype, label it as a prototype. If the live page has changed since the project, record the capture date and avoid suggesting that the image represents its current state.

Separate work completed from business results

“We added an enquiry form and verified receipt with a test message” describes a deliverable and a test. “Enquiries increased by 40%” requires a different evidence base: a definition of enquiry, comparable periods, sufficient data and consideration of other changes. One statement cannot be substituted for the other.

When you have credible outcome data, explain its scope and limitations. When you do not, focus on verifiable work such as the pages delivered, the publishing workflow or the technical problems corrected. A well-documented implementation can still help a buyer evaluate your approach without a revenue claim.

Explain the decision that another business can learn from

Include the trade-off that mattered. Perhaps the team launched fewer product pages because those were the only ones with verified specifications. Perhaps a simple enquiry route was chosen while a CRM integration awaited a separate decision. Explain the requirement, the chosen response and what remained outside the project.

This gives the case study a purpose beyond self-promotion. A prospective client can recognise a similar constraint and understand how your team handles it. Keep the explanation tied to the actual project rather than adding generic advice that could appear on any agency’s portfolio.

Publish a maintainable case study

Use a clear title, a short project summary, descriptive headings and links to the relevant service or permitted live work. Include dates and a responsible author or organisation. Keep the text readable without requiring the reader to extract important information from screenshots.

Review the page when links, permissions or project details change. Correct unsupported statements rather than merely refreshing the publication date. A concept project can remain useful if its status and purpose are clear; a client project should not imply continuing endorsement beyond the permission and evidence you hold.