How to write a portfolio case study that gets read
Hiring teams skim. Lead with the outcome, show three decisions instead of thirty screens, and keep the process to what changed the result.
Most portfolios are read in a hurry. A design lead with forty applications will open yours between two meetings, scroll, and decide within a minute or two whether to keep going. That is not unfair, it is simply how hiring works when there are many good candidates. A case study has to be written for that reader.
Start with the outcome
Open with one or two sentences on what changed because of the work: what was launched, for whom, and what it made easier or better. A line like "We redesigned the onboarding for a banking app; sign-ups that reached the first transfer went from 38% to 52%" tells the reader in ten seconds why the project matters. If you do not have numbers, describe the change in plain words: what users could do afterwards that they could not do before.
Then give the context in a few lines: the company, the team, the timeline, your role. Save the long story of the brief for later, or leave it out.
Show three decisions, not thirty screens
The strongest case studies are built around a few moments where the project could have gone another way. Pick three. For each, show the options you considered, what you chose, and why. One annotated image per decision explains more than a gallery of final screens, because it shows how you think, which is what the reader is trying to find out.
Good decisions to show are the ones with trade-offs: simplifying a flow at the cost of a feature, choosing a typeface that works in twelve languages, cutting a beautiful idea because it did not test well.
Be clear about your part
Almost all real design work is team work, and reviewers know that. What they need to know is what you did. Name the team ("with two product designers, a researcher and four engineers") and then use "I" for your own contributions. If the visual identity was set by someone else and you extended it, say so. It is the first question you will be asked in an interview, and it is better to answer it on the page.
Keep the process short
Process sections often turn into a list of methods: research, personas, journey maps, wireframes. The reader has seen these many times. Keep only the steps that changed the outcome, and say what you learned from them. A single insight from five user interviews that changed the direction is worth more than a photo of sticky notes.
Show the finished work properly
After the decisions, show the result in context: in the product, on the street, on a phone in someone's hand. Use real content instead of placeholder text, and make sure the images are large enough to see details. If the work is live, link to it.
End with what you would do differently
A short reflection at the end (what worked, what you would change, what happened after launch) shows maturity. It also gives the interviewer a natural starting point for a conversation.
A checklist before you send
- The outcome is in the first two lines.
- Your role and the team are clear.
- Three key decisions, each with an image and a short explanation.
- Process only where it changed the result.
- The finished work in real context, with a link if it is live.
- What you would do differently.
- The page loads quickly and works on a phone.
Two or three case studies written like this are worth more than ten that only show final screens. If you have to choose, choose the projects that best match the jobs you are applying for, and put them first.