Writing a design case study people read to the end

Most design case studies are built like a gallery with a caption at the door. A big hero image, a line about the client, then twenty screens in a row and a closing shot of the logo on a tote bag. Nothing is wrong with the pictures. What is missing is the reason anyone should care how they came to exist.

A case study is a piece of writing that happens to have images in it, not the other way round. The people who read one to the end, whether that is a hiring manager, a future client or another designer, are trying to answer a quiet question: how does this person think when the problem is hard? The images show the answer. The words make it legible.

Here is the way we would put one together on RyeType, from the first line to the last image.

Start with the problem, in one paragraph

Before you place a single screen, write the problem as plainly as you can. Not the brief as the client phrased it, but the actual difficulty underneath. “Redesign the booking flow” is a task. “People were abandoning the booking flow at the date picker because it assumed they already knew which night they wanted” is a problem. The second sentence tells the reader what success would look like before they have seen anything.

Keep this paragraph short. Who was it for, what was going wrong or missing, and what were you asked to change? If you cannot say it in four or five sentences, you probably have two case studies, and it is worth splitting them.

A useful test: read only your opening paragraph to a friend who is not a designer. If they can tell you what you were trying to fix, you have a beginning.

Show the constraints, because they explain your choices

Design decisions only make sense against the limits they were made in. A muted palette might be taste, or it might be that the product had to print on a thermal receipt. A conservative layout might be timidity, or a development team of two with a fixed release date.

Name the constraints that actually shaped the work. A short list is fine:

• The audience, and anything unusual about how or where they use the thing.
• Technical limits: platforms, existing components, the content management system.
• Brand rules you had to keep, and any you were allowed to bend.
• Time and team, if they changed what was possible.

Readers forgive a modest outcome when they can see the walls you were working between. They are less forgiving when a case study pretends there were no walls at all.

Tell the process as decisions, not a timeline

The weakest middle section of a case study is a diary: “First we did research. Then we made wireframes. Then we tested.” Every project has those phases, so listing them tells the reader nothing about yours.

Instead, pick the three or four moments where you had to choose. For each one, write what the options were, which one you picked, and why. Then show the image that proves it. A pattern that works well:

1. The fork. One sentence on what had to be decided.
2. The options. Two or three directions, ideally shown side by side.
3. The reason. What tipped it: a test, a constraint, a conversation, a hunch you later checked.
4. The cost. What you gave up by choosing this way.

That last step is the one most people skip, and it is the one that reads as maturity. Every real decision has a price. Saying so plainly shows that you saw it.

If you want to show your early sketches and dead ends, do. Rejected directions are often the most interesting images in a case study, because they show the range you considered. Our piece on sharing work in progress has more on presenting rough material without apologising for it.

Let the images carry a caption each

A row of screens with no words between them asks the reader to do your job. Give every image, or every small group of images, a caption that says what to look at. Not “Home screen”, but “The home screen leads with the next booking instead of the search box, because most visits were return visits.”

Captions are also where you can be specific about craft: the type scale, the grid, why a button moved. Keep each one to a sentence or two. If a caption needs a paragraph, that paragraph probably belongs in the main text above the image.

Images in RyeType posts are hosted on the site, so you do not need a separate image host. Do write a short text description for each one, so that readers using screen readers, and readers on a slow connection waiting for the image to load, get the point too.

Be honest about the outcome

Case studies drift towards triumph. It is tempting to end with a big number, but only use figures you actually have and are allowed to share, and say where they came from. “Support tickets about rebooking dropped after launch, according to the client’s help desk” is honest. A precise percentage you half remember from a meeting is not.

Many projects never get a clean measurement at all. The product launched late, the client changed direction, the feature was cut. That is normal, and you can still write a good ending:

• What shipped, and what did not.
• What you learned that you would carry into the next project.
• What you would do differently with more time, or with what you know now.

An ending that admits a loose thread is more convincing than one that ties everything in a bow.

Edit for the reader who skims first

Most readers will scroll the whole page once before deciding whether to read it. Help them. Use clear section headings so the shape of the story is visible at a glance; on RyeType, long posts get a table of contents built from those headings, which makes a case study easy to navigate. Put the problem and your role near the top. Make sure the best image appears early, not just at the end.

Then cut. Remove the sentences that describe what the reader can already see. Remove the adjectives that grade your own work (“clean”, “modern”, “delightful”). Let the decisions and images speak.

Finally, credit everyone who worked on the project with you, and be clear about which parts were yours. A case study that says “I led the interaction design; the visual system was by a colleague” is more trustworthy than one that blurs the line. If the project was under a confidentiality agreement, read writing about client work you can’t fully show before you publish anything.

A good case study is not long for the sake of it. It is as long as the decisions that matter, and no longer. Write those down clearly, put the right picture beside each one, and the work will look like what it was: thinking you did on purpose.