Updated March 2026: This was written in April 2023. I have added notes on how AI tools have changed portfolio expectations and what reviewers look for now. The structure advice remains solid.
Over the years I have reviewed a lot of design portfolios, both as someone hiring for UI roles and as a developer evaluating designers to collaborate with. Most case studies look the same. They follow the same template ("Empathize, Define, Ideate, Prototype, Test"), include the same stock phrases ("I conducted user research to understand pain points"), and somehow all end with a 40% increase in user engagement.
The template isn't wrong. But when every case study reads identically, none of them stand out.
Here's what I have learned about writing case studies that actually work.
Start with the problem, not the process
The most common mistake is opening with your methodology. "I used Design Thinking to..." Nobody cares about your process until they care about the problem. Give context first.
What was broken? Who was affected? What did the business lose because of it?
Bad opening: "In this case study, I will walk you through my design process for a food delivery app."
Better opening: "The restaurant's online ordering system had a 73% cart abandonment rate. People were adding food to the cart and then leaving before checkout. We needed to figure out why."
The second version tells me something is wrong, there are real stakes, and you were tasked with fixing it. Now I want to know how.
Show constraints, not just outcomes
Every project has constraints. Budget, timeline, team size, technical limitations, legacy systems you couldn't touch. Showing how you worked within those constraints is far more impressive than showing a polished final product.
Some examples of what makes a case study more believable:
- "We had two weeks and no budget for user testing, so we used guerrilla testing with five people in the office cafeteria."
- "The backend team couldn't change the API structure, so the checkout flow had to work with the existing data model."
- "The client refused to remove the carousel. So we made it the least bad carousel we could."
These details show that you can work in real conditions, not just academic ones.
Include what went wrong
I can't stress this enough. If everything in your case study went perfectly, I don't believe it. Real projects have setbacks. Include them.
Maybe your first prototype tested poorly. Maybe the users did something you didn't expect. Maybe the stakeholder changed requirements halfway through. Show how you responded. That's where the actual skill is.
A case study that says "our first design had 3 out of 5 test participants failing the checkout task, so we redesigned the payment flow" tells me more about your ability than one that says "the final design was well-received."
Use real numbers where you can
Vague outcomes are unconvincing. "User satisfaction improved" means nothing. "Task completion time dropped from 45 seconds to 18 seconds" means something.
If you don't have exact numbers (which is common, especially for student or personal projects), be honest about it: "We didn't have access to analytics post-launch, but during usability testing, all 5 participants completed the checkout in under 30 seconds."
Honesty about what you measured and what you couldn't is better than inflated claims.
Structure that works
Here's the rough structure I'd recommend, based on what I find readable:
1. Context (2-3 paragraphs)
What was the project? Who was it for? What was the problem? What was your role?
2. Research (short)
What did you learn before designing anything? Keep this focused. Don't list every interview question. Summarize the key insights that drove your design decisions.
3. Key decisions (the meat)
This should be the longest section. Walk through the major design decisions you made and why. Show alternatives you considered and explain why you chose what you did.
4. What you built
Screenshots, prototypes, before/after comparisons. Let the work speak for itself, but add captions explaining what's happening.
5. Outcomes
What changed? If you have data, share it. If you don't, be upfront about it and share qualitative feedback instead.
6. What you'd do differently
This section is optional but powerful. It shows self-awareness and maturity. "If I had more time, I would have tested with a larger participant group" is a perfectly valid thing to say.
What reviewers actually look for
I can only speak from my own experience, but when I review a portfolio, here's my mental checklist:
- Can this person think through a problem? Not just apply a framework, but actually reason about why users are struggling and how to fix it.
- Do they show the messy middle? Sketches, whiteboard photos, early wireframes that look nothing like the final product. Show the work, not just the result.
- Can they communicate clearly? The case study itself is a design artifact. If your explanation of a checkout flow redesign is confusing and hard to follow, I'm going to wonder about your actual design work.
- Are they honest? Did they acknowledge limitations? Did they work alone or with a team? Did they do the research themselves or did someone else hand them the insights?
[2026 update] One thing that has shifted since I first wrote this: AI-generated case studies are now easy to spot. If your case study reads like it was written by ChatGPT (perfectly structured, no personality, full of phrases like "I leveraged design thinking to elevate the user experience"), reviewers notice. The whole point of a portfolio is to show your thinking. If a machine wrote the story, the reviewer learns nothing about how you think.
On the flip side, using AI tools in your design process is completely fine and increasingly expected. Mention it. "I used Midjourney for early concept exploration" or "I generated initial copy variants with GPT and then refined them based on tone guidelines." That shows you can integrate new tools into your workflow, which is a real skill.
Keep it short
The biggest case study problem is length. I have read 5,000-word case studies for a single feature redesign. That's too long. If the reviewer can't get the key narrative in 3-5 minutes of reading, the case study has failed at the very thing it's supposed to demonstrate: communicating effectively.
Cut everything that doesn't support your core narrative. Remove the generic "About the Company" section. Skip the detailed persona profiles unless they directly influenced a design decision. Nobody needs a full-page mood board.
Practical tips
- Write the case study while the project is fresh. Don't try to reconstruct it six months later. You forgot the important details.
- Get a friend to read it. If they can't summarize what you did and why in one sentence after reading it, it's too convoluted.
- Use real screenshots. Mockups are fine, but if you can show the actual product in production, that carries more weight.
- Don't use the same template for every case study. If all three of your case studies have identical section headers, it looks like a factory output. Each project is different. Let the structure reflect that.
The best case studies don't feel like case studies. They feel like someone telling you a story about a problem they solved. That's what you're going for.