Structuring a case study

A case study explains a project: the problem, your role, what you did, what you decided and what happened. A reliable structure:

1. Summary: one paragraph plus key facts (role, team, timeline, tools) and the main outcome. Many readers stop here.
2. Problem and context: who the users are, what was wrong and why it mattered.
3. Goals and constraints.
4. Process highlights: research, insights, ideas, iterations. Choose the moments that show judgement, not every step.
5. Solution: the final design, explained.
6. Outcomes: results, measures and feedback.
7. Reflection: what you learned and what you would do differently.

Story, not a process diagram

Avoid listing every method you used ("empathise, define, ideate…"). Instead, tell the story of key decisions: what you learned, how it changed your direction and why.

A clear structure lets reviewers quickly find what they need, whether they skim the summary or read every detail. Stories about decisions show how you think, which is what hiring managers are really assessing. Structure also makes case studies easier to present in interviews.

A case study opens with: "I led design on a redesign of a city council's bulky waste booking service. Online bookings rose from 42% to 71% of all bookings in three months, reducing phone calls by about 1,200 a month. Role: sole designer in a team of five. Timeline: 10 weeks."

It then tells three key moments: discovering residents did not know which items were allowed, testing a photo-based item picker, and simplifying payment after a failed first prototype.