In short: To write a design case study people finish reading, start with a one-line summary, set up the problem, state your role precisely, show one or two key decisions with the routes you dropped, say how far the work got and end with a result or lesson. Aim for six to ten images and under 600 words.

A hiring manager opens a case study. The first thing she sees is a mockup of an app on a phone, floating over a pastel gradient. Then a laptop. By the sixth mockup she still doesn’t know what the app does or what the designer did, so she closes the tab.

The next case study in her list opens with one sentence: “A rebrand for a 20-year-old café with a new owner; I led the identity and menu design.” She reads to the end, and that difference is most of what you need to know about how to write a design case study.

A design case study is the part of your portfolio that does the talking when you’re not in the room, and hiring managers finish very few of them. The ones they do finish are built like a short story, with a problem, a turning point and an ending. Most case studies fail as they start at the end, with the finished design, and never give the reader a reason to care how it got there.

How to write a design case study: pick a project with a story

The best case studies come from projects where something got in the way. The budget halved, the factory said no, the client changed their mind halfway through, the research turned up something nobody expected. Constraints are what make decisions interesting, and decisions are what the reader is looking for.

So before you write a word, ask yourself where the turning point was. If you can’t find one, the project might belong in your portfolio as a lighter piece with a few images, and that’s fine.

Write the first line before anything else

Your one-line summary says what it was, who it was for and what you did. “A rebrand for a 20-year-old café with a new owner; I led the identity and menu design.” Put it right at the top.

Some readers will stop there, and that’s perfectly fine; they’ll still know what the project was. Everyone else now has a frame for everything that follows. Writing it first also helps you, as it forces you to decide what the project was really about.

Set up the problem

Two or three short paragraphs: who asked, what they asked for and what was really going on underneath. The café asked for a new logo. What was really going on was a chain opening two doors down, and an owner who needed regulars to feel the place was still theirs.

Include one detail from the real world. A line from a support ticket, a customer quote, a photo of the shop floor, the spreadsheet the client sent with forty product names in it. One concrete detail does more to make a problem feel real than any amount of explanation.

Be precise about your role

On team projects this matters more than anything else in the case study. Hiring managers are reading to find you in the work, and vague phrasing makes that impossible. Say exactly what you owned, what you shared and who else was involved. “I led the identity and packaging; Priya designed the website and I art-directed the photography” leaves no room for doubt. “We rebranded the company” leaves the reader guessing whether you designed the logo or set the business cards.

Tell the decision

This is the heart of the case study and where most of your words should go. Pick one or two decisions, three at most, that changed the outcome. For each one, say what you decided in a sentence, then show what else you considered, ideally with a sketch or an early route. Explain why this one won, with the evidence or reasoning behind it, and say what it cost, if it cost anything.

A UX designer might explain why they moved phone verification to the end of onboarding, and show the earlier flow that lost a third of users at that step. An industrial designer might show the three leg joints they prototyped and the one the factory could actually make at the target price. Two decisions, explained well, are plenty.

Show the messy middle

Sketches, test prints, paper prototypes, the animatic, the foam model that collapsed. Process work makes a case study believable, as it proves the final design was a choice. Give each image a one-line caption so it reads on its own, since plenty of people only look at the pictures.

Leave out process diagrams copied from a course. A neat “discover, define, develop, deliver” graphic tells the reader you took the course. Your own sketches tell them how you think.

Say how far it got, then stop

Be specific about where the project ended up: concept, prototype, launched, in production, on shelves. If it shipped, mention what changed on the way, such as tolerances that moved at the factory, empty states nobody had designed or a print proof that needed a second round. If it stopped, say where and why. Readers respect honesty about a project that didn’t make it far more than a vague “launched” that falls apart in the interview.

End with a result if you have one: sign-ups, sales, test results. Feedback works if you don’t. A lesson works if you have neither. One honest line is enough, and then you’re done.

A design case study example, before and after

Here’s what the difference looks like in practice.

Before: “I redesigned the onboarding flow to improve user experience and engagement.”

After: “New users were dropping off at the SMS verification step. I tested a version that let them explore the app first and verify later, and drop-off fell during the first two weeks of testing.”

The second version gives the reader the problem, the decision and the result in two sentences. That’s the whole case study in miniature, and it’s a good test of whether you know what yours is about.

How long should a design case study be?

Short enough to read in about three minutes. As a rough guide, that’s six to ten images and under 600 words of text. You can go much deeper in the interview, and you will, as a good case study makes people want to ask. 

Once it’s written, run your portfolio through Before They Click, our design portfolio checklist.