What a case study does
A finished design shows what you made. A case study shows why and how. It tells the story of one project so that a reader can judge your thinking as well as your visual skill. For many reviewers, this is the difference between a pretty image and evidence that you can handle real problems.
Case studies do not need to be long. Many are a few hundred to a thousand words, supported by images. What matters is that they are clear, truthful and organized around the decisions that shaped the project.
Pick the right projects
You do not need a case study for every piece in a portfolio. Choose two or three projects that:
- had a clear problem you can describe in a sentence or two;
- involved real decisions and tradeoffs;
- you can talk about confidently;
- have visual material from different stages, such as sketches, drafts and final results.
A project with a modest result but an interesting process can make a better case study than a flashy one where you cannot explain what you did.
A simple structure
Most effective case studies follow a version of the same arc.
Overview
Open with a few lines: what the project was, who it was for, when it happened, how long it took and what your role was. If you worked in a team, say which parts you handled. Reviewers want to know exactly what you personally contributed.
The problem
Describe the situation and the need. What was the client or organization trying to do? Who was the audience? What constraints existed, such as budget, time, existing materials or technical limits? A clear problem statement makes everything else easier to follow. If you started with a formal design brief, summarize it.
Research and discovery
Explain what you learned before designing. This might include reviewing similar work, talking to the client or users, studying the context or collecting references. Share what you did, not an inflated version of it. If your research was light because of limited time, that is fine to state plainly.
Process and exploration
This is the heart of the story. Show early sketches, alternative directions and the reasons you chose one over another. Good material includes:
- rough sketches or wireframes;
- a few options that you did not pursue, and why;
- moments where feedback changed your approach;
- decisions about type, color, grid or structure, explained in terms of the problem.
Explaining a choice such as a type pairing or a restrained palette by connecting it to the audience and goal demonstrates professional reasoning. Also describe any collaboration. Working through client collaboration and revision rounds is part of real projects, so mentioning how you handled it is a plus.
The solution
Present the final work with strong images, in context where possible. Walk through how it addresses the problem, pointing to specific features. Keep the focus on how the design works, not on adjectives.
Outcome and reflection
Say what happened. If you have reliable results, describe them accurately and attribute them correctly. If you do not, say so, and describe what the work was intended to achieve or how the client responded. Never invent figures or imply results you did not measure.
Then add a short reflection: what you learned, what you would change, what you might test next. Admitting imperfections tends to make a case study more credible, not less.
Be honest
Honesty is the most important rule. A few points follow from it:
- Credit others. Name teammates and their roles, and do not claim shared work as solely yours.
- Do not rewrite history. It is tempting to present a messy process as a neat sequence. You can simplify, but do not fabricate stages you never went through.
- Label practice work. If the project was self-initiated or a concept, say so.
- Respect confidentiality. Check what you are allowed to share, and blur or omit sensitive details if needed.
- Be careful with causation. If sales rose after a redesign, many factors may have contributed. Describe the facts without overstating the design’s role.
Writing tips
- Lead with the point. Use headings and short paragraphs so a skimming reader can follow.
- Use plain language. Avoid jargon and buzzwords; say what you did.
- Show, then tell. Pair each section with an image, and keep captions informative.
- Write in the first person where appropriate. “I tested three layouts” is clear.
- Be selective. Include the decisions that matter, not every step.
- Edit. Cut repeated points and read it aloud.
Design the page too
The case study is itself a piece of design. Use a clear hierarchy, comfortable line length and generous white space. Keep images large enough to see details, and make sure the page reads well on a phone. If a long page is necessary, consider subheadings that let people jump to the part they care about.
Common mistakes
- Showing only final images with no explanation.
- Writing a long diary of every step.
- Using vague claims such as “improved the user experience” with no detail.
- Hiding your role.
- Leaving out problems or compromises, which makes the account seem unrealistic.
- Overstating results.
Keeping them useful
Revisit your case studies from time to time. Update them as you grow, replace weaker ones and trim anything that no longer reflects how you work. When someone asks a follow-up question in an interview, your case study doubles as a set of notes for the conversation, and a truthful account is much easier to talk about than a polished fiction.