Jeff Zych

Ingredients for a great product design case study

While I was the Head of Product Design at LaunchDarkly, I hired 12 people in a year and a half. In that time I looked at a lot of case studies from product designers (on the order of 100s, I’m sure) and saw examples of great ones and terrible ones and everything in between. I’d like to share more case studies of my work, so I wrote down what makes for great case studies and bad case studies to guide me when I start writing them.

The best case studies I’ve read…

  • Are short and scannable, but had enough depth to answer questions I had while scanning, and enough detail to show me your skills.
  • Have plenty of pictures, from screenshots of the final work to process shots during the project (sketches and wireframes, the team at a whiteboard, etc.).
  • Provide enough context for me to understand the product, business context, users & customers, problem, goals, constraints, etc. (but kept just to the bare minimum so I can understand the work).
  • Also include context about your role, and what you did.
  • Are well-written and easy to follow. Writing the project like a story usually makes it more engaging (as opposed to just point-by-point saying the steps you went through. “First we did research. Then we…”).
  • Get me invested in the problem you’re solving and make me want to know how you solved it. This will hook me into reading the case study and pull me through to the end.
  • Have a clear impact that’s contextualized so I know if it’s actually impactful or just metrics theater.
  • Impress me with your craft and attention to detail.
  • Showcase projects with enough depth to highlight everything above, without being so sprawling and broad that they just skim the surface of what you can do. Some of the most interesting work I’ve seen in case studies (and in portfolio reviews) were smaller projects that went deeper into the decision making process and craft (but were still impactful).
    • That’s the advantage of smaller projects — they can go deeper on a narrower problem. Case studies of big projects can go too broad and lack the depth that really shows the level of care and detail a great designer will put into a project (of any size).
  • Ultimately, a great case study shows me how you work and your strengths, leaving me wanting to work with you.

The worst case studies…

  • Are confusing, long-winded, and hard to scan.
  • Don’t show me the work, or just have 1 or 2 screenshots with no explanation of what I’m looking at. (This can be especially bad in product design work where the thing you did might be a small piece of the screen it lives in, and/or more conceptual work like system design and information architecture.)
  • Converse of the above, some only have pictures, with no context explaining what they are, what the feature/product does, who the users are, etc.
  • Lack context. Who was this for? What does the product do? What problem were you solving? Why was it worth solving? Etc.
  • Don’t show me your process, how you got to the end result, or how you make decisions along the way. They just show the final product.
  • Don’t emphasize your strengths. If you say you do everything, I’m left thinking you’re not great at anything (no one can master every UX skill).
  • Leave me wondering what you did versus the rest of the team (especially if you worked with any additional designers)
  • Don’t tell me the impact. So you designed and shipped a thing. Did it matter? What was the impact to customers and the business?
  • Go way too deep on theory and idealized product design/discovery processes rather than telling me what you actually did.
  • Formulaic. They followed a template and just rotely filled in the details (sometimes incorrectly). These are an instant turn off and boring to read and you can smell them a mile away.
    • This is most common with case studies of designers coming out of bootcamps, and I don’t want to come down too hard on people trying to break into the field of product design. Templates are useful in these situations, and for entry-level roles I won’t give negative marks to anyone who follows a template. But once you have a few years of experience under your belt, it’s time for your case studies to grow up.

So where does that leave us? My ideal case study includes these ingredients (doesn’t need to be in this order):

  • Context: Help me understand what I’m looking at. Specifically, what’s the problem? Who is it a problem for? What are users trying to accomplish? What are their pain points? Is this an evolution of an existing feature or wholly new? What are the business goals and stakes? Why was this project important? Constraints? Scope? What’s the team team you worked with, and your role specifically?
  • Solution: Show me the designs! How did you solve the stated problem? Ideal case studies have a screenshot with a “wow!” factor that draws me in, but that favors visual design (or designers who work with good design systems), so this will depend on the nature of the project.
  • Process: How did you get to that solution? What alternatives were considered? Convince me that your solution was the right or best one given the context above. Also make sure to highlight:
    • Attention to detail: What details did you obsess over? What made it special/unique/yours? Give me an indication of your craft skills.
    • Strengths: Show off your strengths and how you applied them to this project.
  • Impact: What was the impact? Did it solve the problem? How did you measure that? Business impact? Customer impact? The best case studies have both business impact and customer impact, with both quantitative and qualitative measures (but not all projects have these, so at least one measure is better than nothing).

Great case studies include the ingredients above while minding these constraints:

  • Short as possible (for busy recruiters and hiring managers), while providing enough detail to answer questions they might have while scrolling through the work, and showcasing strengths, craft, and attention-to-detail.
  • Visual. Show at least one screenshot of the finished thing up top. Choose an image that looks appealing and makes me want to learn more. Include pictures throughout the case study to break up the text. Include in progress work, process shots, diagrams, the team together, etc.
  • Scannable. I should be able to scroll through it and have a good sense of your work without reading (pull quotes, captions, and bolding help here).

These ingredients resonated with me as a hiring manager and are what I’ll be aiming for with my own case studies. I hope they help you, too.

Previous article « On Creativity: My modest guide to being more creative
Next article Experimenting with layering, filtering, and masking in CSS »