A web design case study clients finish reading
Most case studies are written for other designers: process diagrams, mood boards, the font rationale. The person deciding whether to hire you wants to know one thing — did it work for a business like mine?
Four parts, in this order
Every case study that does its job answers the same four questions. If a paragraph does not serve one of them, cut it.
- The problem, in the client's words. What was broken or missing before you arrived.
- The constraint. Budget, deadline, an existing platform, a legacy system — the thing that made it hard.
- What you built. Specific decisions, not a list of pages. "Priced quotes in the browser from live supplier options" beats "custom product page".
- What changed. A real outcome, stated plainly. If you do not have a number, describe the change — never invent one.
One live link beats ten screenshots
Screenshots prove you made a picture. A live link proves the site exists, works and is still in use. Put the link at the top, not buried after the gallery.
Then keep it alive. A case study that links to a parked domain two years later is worse than no case study: it tells the reader your work did not last.
Write outcomes you can defend
"Increased conversions by 300%" invites the question you cannot answer: measured how, against what? A concrete description of what changed is more persuasive and harder to doubt — "quote requests stopped being an email thread; the first message now arrives with the spec attached".
If the client gave you a figure and agreed you could use it, use it with its source. Otherwise, describe.
Keeping case studies current
Bowerdeck keeps a case study attached to the live site it describes. Each project holds the write-up, a daily screenshot and its uptime, and can go into a link sent to one client. If the site dies, the project stops appearing publicly until it comes back.