Project Title
One sentence that puts the reader in the problem, not the solution.
| Role | Your Role |
| Client | Client / Internal |
| Status | Launched · Year |
| Tags | tag · tag · tag |
Key Learning
The single transferable insight from this project. What would you tell someone starting a similar project? Not a summary of the case — the one thing that changed how you think. (Optional but preferred. Cut it if you can't find something honest to say here.)
Overview
The situation before the work started. Who was doing what, what wasn't working, and why it mattered. Lead with the user or the constraint, not the outcome. Don't summarize the solution — that's what the rest of the case is for.
The Constraint
What made this specific and hard. Not a generic challenge statement — the actual thing that shaped every decision. If the constraint doesn't explain why the approach looks the way it does, it's not specific enough.
Approach
How you worked through it. Use h3s when there are distinct decisions worth explaining. Each h3 should answer why that decision was made, not describe what was built. If there's only one thread, no h3s needed.
The first decision
Why this decision, and what it was a response to. What would have happened if you'd made the obvious choice instead?
Caption describing what the image shows and why it matters.
The second decision
Same approach. The h3 label should name the principle or the design decision, not the deliverable or the feature.
Caption.
Outcome
What shipped, what changed, what the people using it experienced. Concrete over abstract. If there are numbers, use them. If there aren't, describe the qualitative shift.
Caption.
What I Learned
Honest reflection. Not a verdict on the work — something that changed how you think or work. Cut it if it ends up being generic ("communication matters," "constraints drive creativity"). Those sentences are true of every project and say nothing about this one.
