Every designer has at least one project that deserves better than three screenshots and a one-line credit. You did the thinking, you defended the work in review after review, you rewrote the same paragraph six times. Then it lands on the portfolio as a picture with a caption. A case study template solves that — not by making your writing generic, but by asking the right questions in the right order so the interesting parts of the work stop hiding.

What a Case Study Is Actually For

A case study is not a documentary of your process. It is an argument that you can be trusted with a similar problem. That distinction changes everything about how you write one.

Most people reading your portfolio are skimming. They have a dozen tabs open and four minutes before a meeting. They want to know what was broken, what you decided, and what changed as a result. Give them that inside the first few lines and they will keep reading. Bury it under three paragraphs about the kick-off workshop and they will not.

So write for the skimmer, then reward the reader who stays. Aim for 700–1,000 words per project. Longer is not more thorough; it is usually less edited.

Step One: The Problem, Made Concrete

"Redesign the booking flow" is not a problem. It is a task. The problem sounds more like this: people were abandoning at the third step because the date picker only showed availability after they had chosen a time slot, and they gave up rather than guess.

A useful problem statement covers four things: who was affected, what it cost them (time, money, confusion, trust), why it had gone unsolved, and what was off-limits. That last part matters more than most people admit. Deadlines, legacy systems, brand rules and legal constraints are not excuses — they are the conditions that make your decisions interesting.

A quick test

If another designer could have written your problem statement without ever seeing your work, it is too vague. Specificity is what makes a portfolio piece feel like it belongs to you. Keep this section to around 100–150 words; you are setting up a question, not answering it.

Step Two: The Process, Told Through Decisions

This is where most case studies fall apart. They list activities: research, wireframes, testing, handoff. That reads like a CV in paragraph form, and it tells the reader nothing about how you think.

Instead, pick two or three moments where you chose one path over another, and explain the trade-off honestly. A few prompts that reliably produce good material:

• What did you learn that surprised you, and what did it change?
• What did you try that did not work, and what told you to stop?
• What did you argue for, and what did you give up to get it?
• Which constraint shaped the final design more than any preference of yours?

A sentence or two on each is plenty. Then treat your visuals as evidence rather than decoration. Two annotated screens, with captions explaining what the reader should notice, beat ten unlabelled mock-ups every time. If you worked in a team, be precise about which parts were yours — vagueness here reads as either padding or claiming.

Step Three: The Outcome, Without the Adjectives

"The client loved it" is a feeling, not an outcome. Numbers are stronger when you have them, and you often do: completion rates, support tickets, time saved in a weekly task, how many rounds of revisions it took before sign-off. Use the ones you genuinely measured, and say plainly when something was never measured.

When hard data is unavailable, observable signals still count. A design that survived a legal review unchanged, a component that was reused across three other products, a stakeholder who asked for the same approach next quarter — these are real evidence. What you must avoid is invention. Hiring managers have read a lot of portfolios and can sense a fabricated percentage.

Finish with what you would do differently now. It shows judgement, and it quietly signals that you are not precious about your own work.

The Template Itself

Copy this structure and reuse it for every project. The consistency is part of the value — after three case studies, a reader starts to trust the way you think.

1. Context (two or three sentences): what the product is, your role, who else was involved, roughly how long it took.
2. The problem (100–150 words): who was affected, what it cost, what was off-limits.
3. Constraints: three or four short bullets. Keep them factual.
4. Process (two or three decision moments, roughly 100 words each): what you knew, what you chose, why.
5. Visual evidence: three to five images, each with a caption that says what to look at.
6. Outcome: what changed, with the honest version of your measurement.
7. Reflection: two or three sentences on what you would change.

The Editing Pass That Does Most of the Work

Draft first, cut second. The cutting is where a decent case study becomes a good one.

Remove process narration that does not lead to a decision — the two weeks of exploring directions rarely needs more than a sentence. Replace jargon with the plain action it describes: not "we leveraged a holistic approach" but "we tested the labels with six customers and rewrote three of them". Read the first sentence of every paragraph in sequence; if the piece still makes sense, your structure is holding. If it does not, the problem is usually in the middle, not the opening.

Give the draft to someone outside design. Ask them to tell you what problem you solved and what you decided. If they cannot, the writing is not finished.

Put It to Work

Pick one project from the last couple of years — ideally one where you made a judgement call, not necessarily the one with the prettiest screens. Write the problem and the outcome first, about twenty minutes each. The middle fills in far more easily once you know what the piece has to prove.

Then run the same headings over a second project. Keep each case study dated or note when the work happened, so readers can place it. Once a year, reread the set and update anything that now feels overstated — portfolios age, and a little maintenance keeps them honest.

Photo: Vitaly Gariev / Pexels