Stumbled upon this useful guide by Katarina Batina from Shopify for talking about projects in case studies and presentations. There's been criticism lately about the increasing use of "recipes" to structure case studies, but I still believe a list like this has value. It can help us maintain key points and structure in mind.
I copied and pasted some of her content below:
Outside of evaluating the core skills of a designer, what many hiring managers are looking for is the designer’s ability to understand the context of their work. The better a designer understands the context for the problem they are trying to solve, and why that problem is valuable to a business in the first place, the better the designer can understand the process they should employ to solve that problem and the higher the likelihood they land on a solution that is successful.
- Problem statement
- What problem were you trying to solve and for whom? Think about who the primary user(s) for whom you were solving that problem (it's not always consumer facing, perhaps it was an internal team, etc)
- Desired business objective
Why was the project you're working on prioritized in the first place?
What was the business hoping to achieve by this problem being solved? The answer here may range widely from "there was a desire to explore a broad area and derive learnings from early research to decide if the business should invest further in a particular area" to "driving new user growth."
- Measure of success
Based on the objective, how would success be measured? While this is usually quantitative, there are often qualitative ways to measure success as well, often there's a mix of both.
- Who was the target audience?
- What did you/the team understand about the existing behavior of the target audience? Were there qualitative or quantitative data or insights that helped inform the team about how it might improve or create a new solution for the target audience?
- What was the timeline for the project?
- Were there limitations in budget, technology (limitations in changes that could be made to the existing stack), etc?
- Were you iterating on an existing product/feature or were you developing something new?
- How did you explore the problem space?
- What tools/resources/people did you rely on to help you understand the problem space? Did you work with user research? Data analyst? Product manager? Did you conduct your own research?
- Once you defined a potential solution, what was your approach to defining the final design?
- How wide were your explorations?
- How did you move from one exploration to the next? Avoid taking the audience through a broad range of iterations without providing context for why you were exploring different directions.
- How did you arrive at a final solution?
- How was that solution validated?
- What did it take to deliver your design solution?
- What challenges did you face in getting your solution shipped? Were there trade-offs you had to make from a scope or technical perspective?
- Did the solution you ship solve the stated problem?
- How did the solution impact the intended business outcome?
- What did you and your collaborators learn from what was shipped and how did you determine where to go next?
- What if anything might you have done differently?
- What did you learn during the course of the project?
- How did the project help you grow?