5 Principles of Exceptional Case Studies in UX Portfolios
Taylor Palmer ·
Portfolio
Working on your portfolio?
Check out our new course Master Your UX Portfolio. We’ll show you what hiring managers are looking for and how to make a strong portfolio.
View detailsI’ve reviewed hundreds of UX portfolios over the years as a hiring manager and as someone who enjoys building portfolios.
In one instance, I was hiring and job searching at the same time. While reviewing candidates’ portfolios I was also sharing my case studies with employers to find a new role. It was a very unique opportunity to be on both sides of the hiring process at the same time.
Throughout these experiences, I collected thoughts and ideas about what makes a UX case study exceptional.
- An exceptional case study is unique
- An exceptional case study keeps the audience in mind
- An exceptional case study sets expectations upfront
- An exceptional case study tells a story, not a process
- An exceptional case study answers “why”
- Wrapping up
An exceptional case study is unique
When I started drafting this article I considered developing a template that would be easy to fill out. But you don’t need one. A case study is your own personal experience. You’re the only one who can tell it from your perspective.
This is your story to tell. It doesn’t have to follow the exact formula of every other UX portfolio. Instead, I’ll offer some ideas that can help you find the right approach for your work.
While interviewing candidates, I have come across portfolios from students or coworkers who worked together on the same projects. Their portfolios were indistinguishable, so I had no way to assess their unique skills, perspectives, or contributions. How can you use your case study to showcase what makes you different from other designers?
While every case study should be different, it still has to meet the expectations of a hiring manager. Expectations change based on the size of the company, the maturity of the design team, your seniority level, and the specific role itself. Like any good writer, you need to write for your audience.
An exceptional case study keeps the audience in mind
I’m going to repeat what others have said many times before: your portfolio is just another design project. You need to understand your user (or reader) and their needs, then develop the right solution for them.
Here are some ways to keep that audience in mind:
- Highlight important parts of the case study. What are you proud of? What sets you apart? This content should stand out.
- Pick the right length for your project. Because this is your own story and perspective, there is no perfect length for a case study. However, it should be long enough to interest the hiring manager in talking further. One paragraph is too short, but a diary of the entire project is too long. Aim for the highlights.
- Use headings to make your case study scannable. This showcases your understanding of typography and hierarchies and makes it much easier to browse.
- Write descriptive headings. Each heading should work to your advantage. Headings like “Research” and “Wireframes” tell the hiring manager that you did the same thing any other designer would do. How can you use that valuable real estate to give extra context? Instead of “Research” try something like, “Discovering how much customers care about privacy.”
An exceptional case study sets expectations upfront
The first thing your case study should do is set the stage. Create a scene, give your story a setting, and help the reader know what’s coming next.
Show the end result first
Start by showing the end result of your project. What did your final design look like? Your readers should how good this is going to be in the end! Then deconstruct and show how it all came together.
Starting with the end result gives the reader a sense of what the project involved (mobile vs desktop, app vs web, enterprise vs customer, etc). It prevents them from having to look for those details while scanning the case study.
This also helps readers frame what else they’re seeing. As they read about your research, data, or exploration they can picture the solution and the format in context.
Refine your lead
What’s the shortest way to describe your project while still catching the reader’s attention?
Don’t couch the lead in the middle of a paragraph somewhere. Highlight it and make it stand out! The right pitch could answer many of the hiring manager’s questions right off the bat. Here are some examples to help you think about how you can describe your own project:
- “After observing almost 30 people watch videos on our e-learning platform I worked with my team to develop a new note-taking system. Usage of our education videos spiked almost 20% shortly after release.”
- “My team set out to find the root cause of dropping conversion rates in an enterprise SaaS platform. After 6 months we rolled out an entirely new registration process to better showcase the capabilities of the platform. This resulted in a 5% increase in conversions.”
- “For a school project, I worked with individuals who experienced vision loss to develop an app idea that would improve their movie theater experience. One individual called the idea ‘magical.’”
- “While attending a UX bootcamp I explored app ideas for how to help owners find their lost dogs and created a mockup based on research.”
Answer big questions early
In addition to your lead, answering these questions upfront will make for a much better reading experience. You could present this data as bullet points, a table, a short summary—it doesn’t really matter. What matters is that you clearly communicate the context so the reader can accurately understand the story you’re about to tell.
A hiring manager may have questions such as:
- What platform or OS was this project designed for?
- Was this in-house, agency, freelance, student, or exploratory work?
- Was this ever built?
- Did you work with a team?
- What was the timeline?
- What was your role?
- Was this ever released to the public?
- If released, how did you define success?
- What was the outcome?
Answering these questions early not only provides a better reading experience but always satisfies many of the questions you might hear in an interview, as well.
An exceptional case study tells a story, not a process
Your case study isn’t a design textbook. It doesn’t need to explain how the design process works (because everyone reading your portfolio already knows it). Instead, it needs to tell a story of a project and your role in it. Show the wild ride you went on as the design process unfolded. What is the unique and compelling story underlying this project? Why should the viewer care?
Here are a few things to keep in mind to help you stay in story mode and out of textbook mode:
- Stay connected to the problem. Most design projects start with a problem. A reader can’t evaluate your solution if they don’t understand the problem it solves. Ideally, your final solution should clearly solve the initial problem.
- Connect the dots. What did you learn about people, and how did that impact your design? Many case studies list research insights immediately followed by wireframes. How are these connected?
- Tell stories with images. Even product screenshots can tell stories. Spend time on them. Make them interesting. Make it easy to understand how it relates to the work (instead of random isometric grids of app designs). Point to the part that’s different. Compare old and new, or ideas that you threw out and others you kept.
- Show the mess. Your case study doesn’t need to be messy, but your project might be. Messy or negative experiences are okay. Describe the deadlines, the budget constraints, and the limited resources you had to make the project happen. Teams want designers who are still creative under constraints.
- Show what you learned. Even if your project was a complete disaster you can show how you grew and how you approach design differently as a result. If a project blew up in your face, how did you fix it? If the project funding, what did you learn for next time? No one should expect a flawless project, but everyone should expect to learn from past experiences.
An exceptional case study answers “why”
Designers produce a lot of work. We gather sticky notes, produce endless sketches, and create massive canvases of UI exploration. I get it. We do a lot and we want people to know that! Unfortunately, none of that work matters unless we can communicate why it matters.
Why was this the right project? Why was it the right solution for the business? Why was this the best user experience? Why were you valuable to the project?
Photos of whiteboards and sticky notes show that you did work, but don’t show why that work matters. Instead of a photo of your notebook, show what you learned from that exciting synthesis session and how it changed your project!
Here are some things that can help you tell the story of “why”:
- Insights from a surprising user interview that changed the direction of a project
- Qualitative observations from usability testing
- Data and analysis of flows, funnels, and success rates
- Business goals and strategies that affected your priorities
Wrapping up
Some people, like me, love putting together a portfolio. Others dread it. Either way, it’s the current standard for the UX interview process. Be authentic and honest about your work and you’ll find the right fit for you.
This article is more about principles than rigid requirements. These principles are based on my experience and the shared experience of many other talented design leaders. If you deviate from these ideas and find success, please pay it forward so we can all continue to learn and evolve our craft.
Best of luck in creating a great case study!
If this was helpful, consider giving the Twitter thread some love:
