Portfolio pages in this industry follow a familiar formula. A client logo, three screenshots on a tilted laptop, a sentence describing the brief, and a percentage that improved. They are pleasant to look at and tell a prospective buyer almost nothing about whether the agency can solve their problem.
A case study earns attention when it explains the reasoning behind the work. Anyone can commission attractive screens — just as a polished brand still needs real systems behind it. What a buyer wants to know is how decisions were made when the requirements conflicted.
Start with the situation, not the solution
The opening should describe the client’s circumstances precisely enough that a reader in a similar position recognises themselves. What kind of organisation, what size, what was happening operationally that made them look for help.
“They needed a new website” is not a situation. “A building maintenance contractor with sixty technicians was scheduling jobs on a whiteboard and losing an estimated eight hours a week reconciling completed work against invoices” is. The second version does the qualifying work for you, because the reader either has that problem or does not.
Name the constraints
Every real project has limits that shaped the outcome: a fixed budget, a launch date tied to a trade show, an existing accounting system that could not be replaced, a team with no appetite for retraining, a regulatory requirement about where data is stored.
These are the most instructive part of any case study and the part most often omitted, because constraints can feel like an admission that the work was compromised. The opposite is true. Explaining that you achieved the outcome within an awkward set of limits is far more convincing than implying you had a blank sheet and unlimited time. Buyers have constraints of their own and they are watching for signs that you can work inside them.
Show a decision you got wrong
The most credible case studies include something that did not go to plan. An assumption about user behaviour that testing disproved. A feature built and then removed. A phase that ran late because data migration was worse than anyone estimated.
This is uncomfortable to publish and it is the strongest signal of competence available, because everyone experienced in delivery knows projects behave this way. A flawless narrative reads as marketing; an honest one reads as a team that pays attention and adjusts. It also sets a realistic expectation with the next client, which is worth a great deal during the first difficult week of a project.
Explain how it was delivered
Buyers are assessing process as much as outcome. How long did the discovery phase take? Who from the client side was involved, and how much of their time did it consume? Was the software product delivered in one release or several? How was testing handled? What did the handover include, and what does support look like now?
These details answer the question a prospective client is really asking, which is what working with you would be like. A case study that covers only the finished product leaves them guessing, and guessing usually favours the incumbent supplier.
Use measurements you can defend
Improvement figures are worth including when they are attributable and specific. Time saved on a named administrative task, reduction in order errors, dispatch times before and after, number of enquiries handled per person per day.
Vague claims of increased revenue invite scepticism, because too many factors contribute to revenue for anyone to credit a website with it. Where you cannot isolate a number, say so plainly and describe the qualitative change instead. A quotation from the operations manager about what her mornings look like now can be more persuasive than a percentage nobody believes. And get the client’s approval on figures before publishing — a case study that embarrasses a reference is expensive in the long run.
Write for the person who has the problem
The audience is not other agencies and not design award juries. It is a manager who suspects their systems are holding the business back and is trying to work out who to call.
Write in the language that manager uses, keep it long enough to be substantial and short enough to finish, and end by making the next step obvious. A case study that leaves the right reader thinking “that is exactly our situation” has done its job, regardless of how the screenshots look.
