The proof exists. Visitors do not find it.
A city CIO lands on a services page and sees a list of university projects. A provost’s office sees enterprise work. Both leave thinking you do not do what they need, even though the right case study is three clicks away.
Most institutional and agency sites treat case studies as a gallery. They work better as structured content that every page can draw on.
Give every case study the same fields
Decide a short set of fields and fill them for every story:
- Sector: higher education, government, enterprise, nonprofit.
- Platform: Drupal, WordPress, other.
- Services: build, redesign, accessibility, support, AI.
- Problem: one sentence in the client’s terms.
- Accessibility work: yes or no.
- Approved metric: only if the client approved it, with its source.
The last field is the discipline. If a number is not approved and sourced, the field stays empty. A blank field is better than a claim you cannot back up.
Show similar work on every page
With fields in place, a “Similar work” block can show the three closest case studies on each service, program, and sector page. A Title II buyer from a county sees government accessibility work. A university sees higher education projects on the same platform.
This is personalization without tracking anyone. It uses what the page is about, not who the visitor is.
Make the work page filterable
Filters by sector, platform, and service let visitors self-select. Use real form controls with labels, make results announce updates to screen readers, and keep filters usable by keyboard.
Audit the proof while you are in there
Structuring content forces a review. You will find metrics that differ between the homepage and the case study, client names that need fresh approval, and quotes that cannot be traced. Fix them before you syndicate them across the site. For one example of sector and platform labels on case studies, see KWALL’s work page.
Write for answer engines too
A case study with a clear problem statement, platform, and outcome is easy to cite. Start each one with a two-sentence summary that would still be accurate if quoted alone.
A hypothetical: one visitor, two experiences
Imagine a county communications director reading an accessibility services page. On a site with a generic case study list, the first stories are university redesigns, and the director leaves. On a site with structured case studies, the same page shows government accessibility work on the platform the county uses. Nothing about the visitor was tracked. The page simply knew what it was about.
A setup checklist
- List every case study and the fields you already know for each.
- Agree the field list and allowed values with sales and delivery.
- Fill fields for every story, leaving metrics blank unless approved.
- Tag each service, program, and sector page with the same values.
- Build the “Similar work” block to match on sector first, then service.
- Add accessible filters to the work page.
- Review quarterly as new stories are added.
Write the summary first
Every case study should open with two sentences: the client’s problem in their terms, and what changed. Write it so that it would still be accurate quoted on its own, with no number unless the client approved it. That summary is what the “Similar work” block, site search, and answer engines will use.
Keep approvals current
Client approvals for names, logos, and quotes can lapse when contacts change. Record who approved what and when, and recheck before reusing a story in a new place.
Common mistakes
- Too many values. Twenty sector labels make matching unreliable. Keep the lists short.
- Fields filled once, never again. New stories get added without fields, and the block stops working.
- Numbers copied without sources. A metric moves from a case study to a homepage and loses its context.
- Filters that only work with a mouse. Every control needs a label and keyboard support.
What to measure
Watch whether visitors who see a “Similar work” block go on to read a case study or contact you, compared with pages that do not have the block. Look at trends over a few months rather than week to week.
Frequently asked questions
How many fields is too many?
If editors skip fields, there are too many. Start with five or six and add only when a page needs them.
Do we need a new CMS for this?
No. WordPress and Drupal both support custom fields and taxonomies.
Can we use unapproved metrics if they are accurate?
Get the client’s approval first. Accuracy is not the same as permission.
Should every page show similar work?
Every page where a buyer is deciding. Skip it on legal and utility pages.
What if we only have a few case studies?
Structure them anyway. Fields make even a small set easier to match to the right pages, and gaps show you which stories to write next.
Can we include work we cannot name?
Anonymous stories are weaker proof. If you use one, describe the problem and approach honestly and do not add details the client has not approved.
Should case studies have their own FAQ?
Only if buyers have real questions about the project, such as platform choices or timeline. Do not add one for its own sake.
Who should write the two-sentence summary?
The person who led the project drafts it, and the client approves it before publishing.
Next step
If your best work is hard to find, tell us what you are working on.
