Document as you go

Gather what you already have

• ✦Search your old work tools project by project. Look in Figma version history, Slack or Teams threads, tickets, meeting notes, requirements docs, and launch announcements. If you still have access, save what you’re allowed to keep now.
• ✦Check public changelogs and release notes. If your product shipped publicly, its changelog dates every feature. Match it against your old notes, calendar, or tickets to rebuild when you worked on what, and to find work you’d forgotten.
• ✦Under a non-disclosure agreement (NDA)? Check what it allows before you save anything. For how to show restricted work once it’s in your portfolio, see Portfolio strategy.
• ✦Look for the friction. A disagreement over direction, feedback that surprised you, a scope cut. These become the turning points of your case study.
• ✦Count the work that has no metric. Design system documentation, mentoring, and process fixes still count. Note the goal, what you did, and the time or effort it saved.
• ✦Use AI to find insights in the pile, and edit anything it drafts. Paste in your notes and ask what insights it sees: recurring themes, decision points, and what’s missing. If it drafts the case study, you’re the editor: check every claim and make it sound like you.
• ✦No metrics to show? Show what you learned. If you never had the results or can no longer get them, say what you’d do differently now and which assumptions turned out wrong. Reviewers value that reflection more than a project that looks flawless.

At kickoff

• ✦Decide who the story is for. For a promotion, focus on the skills your company evaluates. For a job search, you’ll need more context about the product, the users, and the feature.
• ✦Picture the interview now. Note what you’ll be asked about later: the problem, your part in solving it, the outcome, and the skills it proves.
• ✦Ask for the baseline numbers now. Before anything changes, get the current metrics, how success will be measured, the goals or objectives and key results (OKRs) behind the project, and who’s on the team.
• ✦Get clear on your role. Are you leading the work or supporting it? What would change on the project without your participation? Which skills will your review judge you on?
• ✦Start a single running doc for the project from the start. Use a tool you already work in, like Notion, FigJam, or Google Docs. Leave it open so a note takes seconds.

During the project

• ✦Log each of those moments the same day. Note the decision, why you made it, and what you turned down. For a fuller template, try the free Receipts worksheet (opens in a new tab) from The Content Design Co.
• ✦Keep a short daily log too, separate from your decision log. One line on what you worked on is enough, even if it reads like a timesheet. Later, matched against release notes and tickets, it rebuilds your timeline. When I matched 18 months of my daily notes to a product’s public changelog, I found insights my case studies had missed, and an important project I’d never written up.
• ✦Write down what you expect to happen. Check it against the result later. Over time, you learn when to trust your instincts and when to slow down.
• ✦Capture the story, not only the facts. Note how people reacted, the pushback you prepared for, and anything that caught you off guard. That detail is what keeps an interview panel listening.
• ✦Save evidence as it appears. Early sketches, annotated Figma iterations, rejected copy, requirements docs, key Slack threads, design share-outs, launch announcements, and timelines. Directions you abandoned show how you weigh trade-offs.
• ✦Note each pivot as cause and effect. "We assumed X, testing showed Y, so we changed to Z" is a turning point. A list of tasks is not.
• ✦Connect decisions to data at each stage. Track what changed in alpha, beta, and launch. If hard numbers are slow to arrive, save the early signals: praise from leadership, quotes from internal testers, notes from research.
• ✦Record the scale when there’s no metric. Users affected, markets supported, edge cases covered, teams involved.
• ✦Log how you used AI. Note the tool, what you asked it, how your prompts changed, and where your own judgment took over. See Writing the case study for how to present it.
• ✦Separate what you owned from what the team did while it’s still clear.

At wrap-up

• ✦Hold a retrospective, alone or with your team. Compare the results with what you expected at kickoff, in numbers and in what people said. Note what you’d change and what’s worth reusing, like a pattern for the design system.
• ✦Go back to your kickoff question: what changed because you were on the project?
• ✦Review your log with AI while you can still fill the gaps. Ask it for the main problem, the key trade-offs, and where your evidence is thin.
• ✦Add the highlights to a running list of your wins. Some call it a brag document. Update it every couple of weeks or before performance reviews, and share it with your manager.

Do this / not this