How I write case studies for my product design portfolio
The end of last week was a tough one at work. My company is laying off 10% of its employees, roughly 8000 people. Luckily I was not part of that 10% but it’s still an awful thing to experience. Apart of offering my help I keep trying to think of other ways I can support my colleagues. This post is a small attempt at that.
Many designers have been affected and I imagine that updating their portfolios will be an important task for many in the near future. Updating portfolios is always an arduous task, especially if you haven’t done it for a while, so I thought I’d help.
Introduction to one of my case studies
The following is a framework I created for myself when I did my last website redesign in 2021. It was the first time I wrote proper case studies and I did a lot of research on how to do them right. I’m proud of the two I wrote1 and I’ve received a lot of great feedback on them from industry professionals. I’ve also shared this framework with some of my design mentees working on their portfolios and it’s been helpful for them so hopefully it’ll help you too.
Please let me know if you use it and mostly if you have any feedback or ideas on how to improve it. If you have any question, drop me a comment here, reach out through LinkedIn or maybe book a call with me and we’ll chat about it. Good luck!
Guiding principles
A good portfolio is not just a collection of things you made. It is a collection of how you think.
Story over Process
One common issue I see with case studies is that people over index on their processes. The case studies end up becoming an intro lesson on tools or the design process instead of telling the story of a particular project that highlights the designer’s experiences, skills, and strengths. So my advice is to focus on the story you’d like to tell and let that be the driver of your writing.
Insights over Process
This second principle reinforces the first one with a nuance. While the story is the driver, your own insights, learnings or takeaways from it are one of the most important parts of a case study. Being part of a design project is not particularly special for a potential recruiter but what you learn from it is. Tell stories of, for example, how you came up with an unexpected solution, situations or people that made you change your mind, or ideas that didn’t work and why.
You over Industry standards
Another common mistake is the notion that you shouldn’t deviate from apparent industry standards or ways of doing things. But that’s not the case. There could be good reasons to start a project by doing a high-fidelity prototype instead of extensive research. You might not do a design system for a project, and that’s ok too. The double diamond process is not a requirement for every design project. Highlight your approach, explain your thinking, talk about the impact of your decisions, and help people get to know you as a professional designer.
Starting points
Before you start writing, ask yourself:
- What’s the story I’d like to tell?
- Why am I telling this particular story?
Here’s an example from the case study I’m currently writing…
What’s the story I’d like to tell?
Creating spaces to connect and discuss what we love most about our products with the goal of uniting internal teams through a shared definition of quality.
Why am I telling this particular story?
- Shows how I put my values of compassion and joy into practice
- Highlights my workshop design and facilitation skills
- It’s about design creating impact at scale by providing guidance to make difficult product decisions.
As you write your case study, keep these questions in mind:
- Could someone with zero context understand this?
- Is this adding value or noise to the story?
- Did I learn anything from this that I could highlight?
- Am I using my own words?
Process
- Create a new document in a writing app so you can focus on the content
- Answer the story questions at the beginning of the document to keep them top of mind
- Select the most important sections from below and add them to your document
- Start with the bare minimum, you can add more later
- Write the content for those sections
- Use your own words, plain language, and avoid jargon
- Do your best to not edit as you write
- Avoid acronyms unless the acronym is widely known in the industry
- Balance the use of “I” and “we”. While it’s important to highlight when you collaborated with others, recruiters want to understand the value that you personally added to the project.
- Go back to the list of sections and check if there’s anything else you could add that would be interesting to tell.
- Once you have a first draft, start editing.
- Aim for short sentences and paragraphs.
- Write titles for each of your major sections that summarise the content in one short sentence
- So instead of saying “Impact” or “Results”, I’d say “The color contrast violations dropped an order of magnitude.” I have to thank César Astudillo for this nugget of wisdom.
- Read it all and ask yourself: “Have I told the story I wanted?.” If not, keep editing.
- Move your content to wherever you want to publish it
- Don’t overthinking it, it can be as simple as a Notion page
- Include media (images, prototypes, videos…) to illustrate the case study
- Publish!
- Publish before you think it’s ready. You can always iterate and add more information in the future. Once it’s public you’ll have an even stronger incentive to finish it.
- Ask colleagues, friends, and family for feedback before you send it to recruiters.
Sections
Here’s an unnecessarily extensive list of possible sections you could add to your case study. My intention is that this will serve you as inspiration on what to write about. You definitely don’t need to add them all, not even most. Choose only those that fit your project and story.
Context
- Company
- Start and finish date
- Your role in the project
- What you did
- Team and their roles
- Other teams involved
- Stakeholders
- Overview
- Platform/s
- Industry
- Overview of the design process
- Timeline
Understand the Problem
- Background
- How did this project got started; or
- “How might we…”
- Problem statement
- Target user / Persona
- Needs (user, business, technical…)
- Current experience
- Pain points
- References
- Vision
- Goals
- Discovery
- Research
- Customer insights
- Jobs To Be Done
- Definition of success
- Success metrics
Scope
- Requirements
- Functional
- Usability
- Technical
- Legal
- Instrumentation
- Organizational
- Out of scope
- Constraints
- Dependencies
- Assumptions
- Priorities
Ideate the Solution
- Brainstorming
- Plan
- Workshops
- Design principles
- Sketches
- Information Architecture
- Wireframes
- Mockups
- Prototypes
- Considerations
- Key insights
- Key design decisions
- Design details
- Iteration ideas
- Implementation
- Pivots and why
- Trade-Offs
Outcome
- Results
- Ideas that didn’t work and why
- Ideas shot down
- Aspects skipped to deliver on time
- Design debt
- Metrics / Data
- Impact
- User feedback
- Internal feedback
- Media coverage
- Takeaways
- Mistakes
- Learnings
- Accomplishments
- Workflow insights
- What would you do differently next time
- Next steps for the project
For confidentiality reasons my case studies are password protected. If you’re interested in using them as reference to write your own, please reach out to me in private and I’ll share the password.↩︎