A website case study brief turns a completed project into a useful reference for prospective customers. For a Kenyan business commissioning a new website, the difficult part is often deciding what can be shown and what the project actually proves. A gallery of attractive screenshots does not explain your responsibility, the customer's original problem or the work that was delivered.
Discuss the evidence available with your website development team in Kenya before choosing a case study layout. The page should help a reader assess relevant experience. Its immediate purpose is clarity, rather than a promise of higher rankings or more enquiries.
This guide concerns project narratives and supporting evidence. Customer quotations have a separate testimonial collection and approval process. The planning examples below are illustrative, not claims about projects Mocky has completed.
Choose the buyer question before selecting the project
Start with a question a prospective customer needs answered. They may want to know whether your team can organise a large catalogue, explain a complex service or deliver a handover that staff can maintain. Choose a project that can demonstrate the relevant task using records you are allowed to publish.
Write one sentence describing why this example belongs on the site. An illustrative purpose might be to explain how a supplier's product information became a browsable catalogue. That gives the writer a specific subject. It also helps the designer avoid filling the page with unrelated images simply because they look impressive.
Select fewer projects when the evidence is limited. A small set of accurate examples is easier to review than a large collection whose scope nobody remembers. Keep proposed work, internal exercises and delivered client projects clearly distinguished in the content register.
Build a project evidence sheet
Create a worksheet containing the project name, business context, dates, commissioning organisation, your role, deliverables and publication owner. Add references to approved images and relevant documents. Keep confidential contracts, credentials and private customer records outside the website asset folder.
Separate a source fact from a proposed sentence. A signed scope may establish that catalogue setup was commissioned, while a handover record may establish that particular pages were delivered. Neither automatically proves a sales increase. Ask the responsible project owner to check the statement against the appropriate evidence.
Record uncertainties openly. If the launch date is unclear, resolve it before publication or use a less precise description that remains accurate. Do not choose a convenient date to make an old project appear recent. The worksheet should expose missing information rather than conceal it inside polished writing.
Explain your responsibility accurately
State what your organisation did and which work came from others. A business may have supplied photography, another specialist may have written copy and your team may have built the interface. The case study should explain that contribution without implying ownership of every element visible on the finished site.
Distinguish designing a concept from implementing it. A proposed dashboard is not proof of a deployed reporting system. An approved visual direction is not evidence that physical materials were manufactured. Give each illustration a caption that identifies its status and the part of the project it represents.
Ask collaborators how they should be credited where relevant. Avoid publishing private working arrangements or turning the page into a dispute over attribution. The useful public detail is enough context for a buyer to understand your experience and evaluate whether it relates to their own requirement.
Write the narrative around decisions and deliverables
Use a simple sequence: the starting situation, the agreed task, the important decisions and the delivered work. Explain why a decision mattered. For example, grouping catalogue items by customer use may be more informative than listing every colour used in the interface.
Keep the customer's problem specific without exposing unnecessary internal detail. A reader can understand that staff struggled to maintain product information without seeing private messages, employee names or a screenshot of a confidential spreadsheet. Describe the workflow at the level necessary to explain the project.
Connect each decision to something visible. If the narrative discusses navigation, show the relevant navigation. If it discusses editing responsibilities, explain the handover deliverable. Avoid a long list of fashionable technology names that does not help the buyer understand what was built or how it will be maintained.
Separate delivery evidence from measured outcomes
A completed website, approved design and staff handover are project outputs. Enquiries, qualified leads and sales are business outcomes. They need different evidence. Do not turn the existence of a new enquiry form into a statement that enquiries increased.
For a numerical result, record the metric definition, source, comparison periods and limitations. Ask who has authority to approve its publication. Changes in advertising, product availability or seasonal demand may complicate interpretation. If the evidence is unavailable, describe the delivered improvement without inventing a business result.
Google's guidance on helpful content encourages original information, clear sourcing and useful evidence. For this brief, apply that principle by making the project's facts checkable. A case study does not need a dramatic percentage to explain a real problem and a practical solution.
Select images that explain the work
Choose an opening image that identifies the project and supporting images that show the decisions discussed. Provide the original approved files, intended crops and captions. The website image content brief can help keep those decisions organised.
Check every screenshot for private information. Names, email addresses, order details, browser tabs and internal notifications can appear unintentionally. Ask for an appropriate demonstration image or an approved redacted version. Do not assume that a small screenshot makes sensitive information harmless.
Keep important explanations as readable page text. A screenshot containing tiny interface labels will not communicate every detail on a phone. Add a concise caption explaining what the reader should notice, and review the image at the actual mobile display size before approving it.
Review the whole page with the publication owner
Send the proposed page with its title, copy, captions, logos and attribution together. A list of image filenames is not enough context for meaningful approval. Make clear which details are being proposed for public display and which material remains internal.
Check that a general approval has not been stretched into permission for new claims. If the writer adds an outcome, changes a project status or inserts a customer quotation after review, route that change back to the appropriate owner. Record the approved version and its publication date.
Review the final enquiry route too. A case study about a catalogue project should lead naturally to a relevant service discussion. Ask visitors about their own requirement without implying that their budget, timeline or results will match the featured project. Every new project still requires its own scope.
Keep a maintenance and withdrawal record
Name the person who owns future edits. Record where the case study appears, including service-page teasers and portfolio listings. If a client name, image or project status changes, the editor should know which related placements need review.
Agree how to handle an unavailable live project link. A customer's website may change independently of your work. Decide whether to keep approved dated screenshots, update the link or revise the description. Do not silently present a newer third-party redesign as the work your organisation originally delivered.
Before requesting a quotation, prepare one representative project sheet and its approved assets. Ask for website content setup with case study templates, mobile review and editor handover included. A sample helps the team estimate the actual content work instead of guessing from the number of project names.
Frequently asked questions
Can we publish a case study without a customer testimonial?
Yes. A factual project description can stand on approved deliverables and evidence. Do not invent a customer comment to complete the layout.
What if we cannot publish the client's name?
Discuss an honestly anonymised example with the appropriate owner. Avoid enough identifying detail to defeat that agreement, and do not invent a replacement customer identity.
Should every project include a percentage improvement?
No. Include numerical outcomes only when the source, definition and comparison can be reviewed. Clear delivery evidence is preferable to an unsupported performance claim.
Can we show unfinished work?
Only with appropriate approval and an accurate explanation of its status. Keep proposals and concepts distinguishable from delivered work so readers understand what the example demonstrates.
