A portfolio image shows what a project looks like. A case study explains why the work was needed, which decisions mattered, and what changed for the customer. For a business choosing a designer, developer, or consultant, that context can be more useful than a gallery of attractive screens.
Writing a case study does not require dramatic statistics or a famous client. It requires an honest account of a specific problem and a clear explanation of the work. This guide shows how to plan case-study content that supports a buying decision, respects customer permissions, and connects naturally with the services on your website.
Choose a project with a useful story
Start with relevance rather than visual impact. A project is a strong candidate when it demonstrates a problem your future customers recognise: unclear navigation, difficult content editing, inconsistent product information, or a contact process that needed improvement.
Ask what the project can prove. It might demonstrate how you organised a growing service catalogue, handled a platform change, or designed a more accessible form. The story should have a clear centre rather than becoming a list of everything completed during the engagement.
Consider whether enough information is available to support the account. If customer approval, original screenshots, or project notes are missing, collect them before beginning. Reconstructing the story from memory can introduce claims that were never agreed.
Obtain permission and agree the boundaries
Confirm what can be published: the customer’s name, logo, screenshots, testimonial, project description, and any business results. Approval of the finished website does not automatically mean approval of a marketing case study. Give the customer the actual draft and images to review.
Remove private information from screenshots, including customer records, inbox content, account identifiers, and unpublished business plans. An anonymised case study can still be useful when the constraints are explained honestly. Do not imply that a named company endorsed your work if that endorsement has not been authorised.
Keep the approved version and record who reviewed it. This makes future updates simpler when a customer changes its brand, removes a product, or asks you to revise the description.
Open with the situation and the outcome
The opening should quickly answer who the project was for, what needed improvement, and what the engagement delivered. A short project summary helps visitors decide whether to keep reading. Save detailed background for the sections that follow.
For example, a hypothetical case study could explain that a local service company needed a clearer way to describe its offers and receive enquiries. The project delivered a reorganised website, editable service pages, and a tested contact process. This is specific without claiming that a redesign alone transformed the company’s revenue.
Make the difference between a delivered feature and a measured business outcome clear. “The team can update service content” is a capability. “Qualified enquiries increased” is a result that needs a defined measurement period and supporting data.
Explain the challenge without criticising the customer
Describe the starting situation respectfully. Older websites often reflect previous business needs, limited budgets, or tools that were appropriate at the time. The aim is to explain the constraint, not to make the customer’s former decisions look foolish.
Use observable details. “Visitors had to open several pages to compare services” is more useful than “the old website was bad.” “The owner depended on a developer for routine changes” explains an operational issue. These details also make the solution easier to understand.
Include the constraints that shaped the work: content availability, an existing platform, a fixed launch date, or a small editorial team. A convincing case study shows judgement within those constraints rather than presenting the project as an unlimited creative exercise.
Show the decisions behind the design
Choose two or three decisions that mattered and explain their reasoning. Perhaps services were grouped around customer questions, the main call to action changed, or a content model replaced inconsistent page layouts. Show how each decision responded to the original problem.
Avoid describing every visual adjustment with abstract language. Readers do not need a paragraph about the emotional significance of every border radius. They need to know how the work improved clarity, usability, editing, or consistency.
Screenshots should support the explanation. A navigation comparison, a mobile form, or a content editing view can reveal more than several full-page images. Use clear captions so the reader understands what to notice.
Document your contribution accurately
Clarify which parts you delivered and which came from the customer or another supplier. A project may combine your design and development with customer-written content, a photographer’s images, or an external marketing team’s campaign work.
Accurate attribution builds trust and prevents confusion. It also helps prospective customers understand what they would need to provide on their own project. If you inherited a brand system, explain how it was applied rather than suggesting that you created the entire identity.
For website work, useful contribution headings might include planning, user experience, visual design, CMS development, migration, and handover. Include only the areas actually covered by the engagement.
Present results with their limits
Use numerical results only when the data is reliable and the customer approves publication. State what was measured, over which period, and whether other changes occurred. A campaign, a seasonal shift, or an expanded sales team can all influence performance alongside the website.
If numerical data is unavailable, report practical outcomes: fewer steps to find a service, a reusable page template, an owner-managed project library, or a successful migration with a documented redirect plan. These outcomes can be checked without inventing a percentage improvement.
An honest limitation can strengthen the account. Explain that a measurement plan was established but a longer observation period is needed, or that the scope focused on editing and usability rather than acquisition. Our GA4 lead tracking guide explains how meaningful enquiry measurement differs from counting button clicks.
Connect the case study to a relevant service
A case study should offer a useful next step. Link to the service that addresses a similar problem, another relevant project, or a planning guide. Do not surround the story with unrelated calls to action that distract from the evidence.
Use a descriptive page title, a clear main heading, and an introduction that identifies the project. Search optimisation should reflect the actual case rather than adding every platform and industry keyword you hope to rank for. Google’s title guidance recommends descriptive titles that distinguish one page from another.
If a customer’s live site has changed since your work, label screenshots with their project context. The case study should represent the approved project, while the live link gives visitors an opportunity to explore the current website.
A reusable interview outline
Ask the customer what triggered the project, what was difficult beforehand, which part of the process helped them make decisions, and what they can do now that they could not do previously. Ask your own team which constraint required the most thought and which decision best explains the final solution.
Collect concrete examples rather than requests for praise. “How do you update a service now?” is likely to produce a more useful answer than “Were you happy with the project?” If a response becomes a testimonial, obtain approval for the exact quotation and attribution.
The resulting material can support several assets: the full case study, a short portfolio description, and a service-page example. Adapt those pieces to their purpose rather than publishing the same long text in every location.
Review and maintain the story
Check links, images, customer permissions, and factual claims before publishing. Make sure screenshots remain readable on mobile and have appropriate descriptions. A case study should be useful even when a visitor cannot see every visual detail.
Revisit the page when the customer changes its name, the linked website moves, or the described platform becomes inaccurate. Keep the original project context instead of silently implying that you continue to manage work that ended years ago.
Explore our work and case studies to see how project evidence can support a website. If you want a portfolio that explains your contribution clearly, share your project and we can plan the content alongside the design.