How to Write Case Studies for Your Design Portfolio
A portfolio full of polished screenshots tells people what you made. It rarely tells them how you think. Case studies close that gap. They give a potential client or employer something better than a gallery: a window into your decisions, your working method, and the way you handle the messy middle of a project.
That middle is where most designers get stuck. Writing about your own work can feel awkward, especially when the project had false starts, awkward compromises or a client who changed their mind twice. The good news is that those details are exactly what makes a case study worth reading. Nobody learns much from a straight line.
Start With the Problem, Not the Pretty Pictures
A common mistake is opening with a stunning hero image and a sentence like "I was asked to redesign a website." That is a description, not a story. Instead, set up the tension. What was actually wrong? Who was affected by it? What was at stake if nothing changed?
For example, rather than "The client wanted a new booking flow," try: "Bookings were dropping off at the payment step. Customers were abandoning baskets on mobile, and the team had no idea why." Immediately the reader has a question they want answered, and your work becomes the answer.
Keep this section short — two or three tight paragraphs. You are setting the scene, not writing a business report.
Define Your Role Honestly
Readers need to know what you actually did. Were you the sole designer? Part of a team of five? Did you lead research, or inherit it from someone else? Did you build the thing, or hand it to developers?
Being precise here protects you. Saying "I led the visual design and worked with a UX researcher on testing" is more credible than vague claims of ownership over everything. It also helps people match your skills to their needs, which is the whole point.
A simple structure works well:
- Context: the client, the product, the timeframe, the team.
- Problem: what needed solving and why it mattered.
- Your role: your specific responsibilities and constraints.
- Process: how you got from problem to solution.
- Outcome: what changed, and how you know.
- Reflection: what you would do differently next time.
You do not need to use those labels visibly, but the underlying order keeps you from rambling. Most weak case studies either skip the problem or skip the outcome. Both omissions leave the reader unsatisfied.
Show the Process, Including the Dead Ends
This is the section where portfolios are won or lost. Process is not a list of tools. Nobody cares that you used a particular piece of software. They care about your reasoning.
Walk through two or three key decisions in detail rather than summarising everything. If you tested three layout directions, show them side by side and explain why two failed. A sketch, a rough wireframe, a whiteboard photo — these are often more persuasive than a finished mockup because they show thinking rather than polish.
What to include from each stage
From research: a quote from a user interview (anonymised if needed), a pattern you noticed in support tickets, a competitor gap. From exploration: early sketches, rejected concepts, feedback you received and acted on. From delivery: the constraint that forced a compromise, and how you handled it.
Do not pad this out with every artefact you produced. Choose the evidence that supports your argument, the same way you would in a written essay. Three well-explained decisions beat twelve unexplained screenshots.
Write About Outcomes Without Exaggerating
Outcomes are powerful, but only if they are true and specific. "Increased engagement" means nothing. "The number of people completing checkout rose over the following quarter, according to the client's analytics" is better — provided that is genuinely what happened and you can point to where the figure came from.
If you do not have hard numbers, say so plainly and use qualitative evidence instead. Client feedback, a quote from a stakeholder, the fact that the work shipped and is still in use, an internal award, a follow-up project — all of these count. Never invent metrics, and never claim credit for results that belonged to a whole team or to other factors such as a seasonal sales push.
If the project was cancelled, that can still be a strong case study. Explain what you learned, what you would change, and what you did with that insight afterwards. Honesty reads as confidence.
Make It Easy to Read
Most people will skim your case study before deciding whether to read it properly. Respect that.
- Front-load the outcome. A one-line summary at the top, or a short results box, gives skimmers a reason to stay.
- Use descriptive subheadings. "Testing three navigation models" tells the reader more than "Process".
- Caption your images. A sentence under each visual explaining what the reader is looking at doubles the value of the image.
- Keep paragraphs short. Three or four sentences is plenty on screen.
- Cut the jargon. If a phrase would not survive being read aloud to a friend outside design, rewrite it.
Length matters less than density. A tight 600-word case study with strong visuals will outperform a 2,000-word essay every time.
Handle Confidential Work Sensibly
Many designers worry that their best projects sit behind NDAs. There are usually workarounds. Ask the client whether you can present the work in an anonymised form — no brand names, no real data, no proprietary detail — and get their approval in writing before publishing. Some will say yes if you explain that the case study brings them visibility too.
If permission is refused, you can still write about the problem and your approach in abstract terms, or rebuild a small self-directed version of the work as a personal project. What you must not do is publish client material without consent.
A Practical Way to Start
Pick one project you finished in the last year. Open a document and answer four questions in plain sentences: What was broken? What did I do about it? What happened next? What would I change? Write rough answers first — do not try to make them elegant. Then add three or four images that support your points, write captions for each, and rearrange the whole thing into the order above.
Do that once and you have a case study. Do it for three projects and your portfolio stops being a gallery and starts being an argument for hiring you. Set aside an hour a week and work through your back catalogue one project at a time; the habit matters more than getting each one perfect on the first pass.
Photo: Pavel Danilyuk / Pexels