Landing your next product design job: case study checklist
Ensuring your case studies cover what companies are looking to understand about the work and how you work.
The entire hiring process is all about matchmaking. You’re trying to find the right organization and role to fit your specific needs and career goals, and companies are searching for designers with the skills and experience that match the gaps on their team. But with so many designers submitting their applications, what can you do to stand out and help companies see the amazing designer you are? The best way to tell others your career story is through your work, not just with final polished mockups, but the details of how you got to those final designs using a case study.
But before you can tell the story, you first have to understand your audience and what they care about. Determining what companies are looking for will help you write and present more effective and convincing case studies, which will increase your chances of being moved forward. Often the things we look for are completely omitted from the work we review, which is where the idea for these posts came from: this checklist is meant to give you a peek behind the scenes to help you understand what we look for in all product design candidates, regardless of level, and to help you land that next product design job!
If you haven’t already read the companion post on crafting your portfolio, I’d highly recommend going back and reading it first!
Orient the reader to the business and the project. We often see case studies that launch directly into the process without describing the business or purpose of the project, which means the reviewer will need to leave your case study to do their own research. It only takes 2–3 sentences to give enough context to the reader for them to understand what they need to.
Problem definition for the business and your user. You can have the most beautifully designed wireframes or mockups, but if we don’t know what problem you’re trying to solve for the business and the user, it’s impossible for us to know if the decisions you’ve made were the right ones. That’s where problem statements come in.
Effective problem statements aren’t just important in your portfolio but in your work. Writing great problem statements helps others understand why a problem is important to solve. On the other hand, being able to question and critique ill-formed problem statements helps you ensure that the project you’re working on drives real value and how you define success.
When crafting a problem statement, ensure that you’re actually describing a problem that the user or business has without bias toward a solution. Things like “make the website more appealing” or “how might we improve the shopping experience” or “redesign the website because it’s outdated” are not good examples. A good problem statement identifies who specifically is affected, what their problem is, and why it matters (what impact this problem has). A couple of examples: “solo lawyers are not trained to be small business owners and lack the marketing skill to find new clients, which limits the growth of their business” or “new users have difficulty creating and sharing bills, which decreases the amount they’re able to collect each month.”
Your users. Even though users are at the centre of everything we do, they’re often neglected in the portfolios we review. Help us understand who your users are, what makes them unique in how you designed for them, and how you came to understand them at a deeper level through research.
Outcomes for the business and your users. Well-formed outcomes are the most important part of a project and are also the thing we see most often omitted. Describe the impact the project had on the business and your users, and how the world is different as a result.
Measuring success (or failure). Quantifying the outcomes is how we actually know if a project was a success or failure. So, what metrics did you plan to measure and move, and by how much? What specific UX metrics show the problem was solved for your users effectively? Which business metrics did you impact?
Discovery research. What did you do to understand your users and the business at a deep enough level in order to identify the problems to be solved? Which research methods did you use? Did you use quantitative research to strengthen your qualitative findings? Did you investigate the competitive landscape? What were your key findings from the research you undertook?
Ideation and solution exploration. Design problems never have just one solution, they have several. What did you do to uncover several approaches to solving the problem? Did you work with others to further broaden the number of possibilities? How did you determine which were viable and which weren’t?
Testing. We never get it right on the first pass, it always takes several iterations before we land on a version of the design that matches the needs of our users, the business, and the feasibility of what we can build. How did you go about testing your work? Who did you test with and how often? Was there intention behind what parts of the design you tested at each stage? (concept testing VS workflow VS information architecture VS usability VS content) What did you learn and how did it change your approach to the design?
Collaboration and feedback. Product design isn’t a solo activity, it’s a team sport. We work closely with other disciplines and other designers in different capacities depending on the project stage and the specific needs of the project. Tell us who you worked with and how you collaborated with them at different phases of the design process. Did you get your work critiqued by others? Were there key pieces of feedback that affected your decisions and the final design?
Retrospective. Does your project not check everything on the list? Don’t sweat it too much! We understand that the real world is messy and nothing is ever ideal. If a project is missing something important (like you weren’t given the budget to do usability or iterate on a second version), don’t shy away from it. Add a “what I learned” or “what I would do differently next time” section so you can talk about how you grew or what you will change in the future.
Hopefully this post will help you write and present your case studies so they speak to what your audience is looking to understand about how you use the design process and the impact your work has had on the business and your users. Best of luck finding and landing the product design role you’re looking for!
If you’re interested in finding out more about Clio and applying to the Product Design team, check out our careers site.
Special thanks to Claire Pacheco, Irina Belova, and Maria Pereda for your feedback and help on these posts! Photo credit: @pamivey
