The Story You Can Tell Depends on the System You Used to Collect It
by Scott Purcell
The story you can tell at the end of a project is determined by the system you used at the start. Storytelling isn't something you do after the work. It's something you build into it.
Most designers already know storytelling matters. They've heard it. They believe it. The gap isn't conviction, it's mechanics. How do you actually collect the evidence that makes a story worth telling? How do you structure it so the narrative is there when you need it, instead of something you have to reconstruct from memory months later?
That's what this post is about.
Start with the Frame, Not the Output
Before any work begins, you need to define three things: who you're doing it for, what you're trying to deliver for them, and how you'll know it worked. This isn't project management overhead. It's lean live-documentation and sets up a storytelling scaffolding.
When you know the frame going in, every decision you make during the work becomes a data point in the story you'll tell later. Without it, you end up with a pile of outputs and no coherent account of what they mean or why they matter.
A simple version of the frame:
Who: Who is this for? Be specific — not "stakeholders," not "users." Name the person and their situation.
What: What value are you delivering for them? Not what you're building — what changes for them when you succeed.
Why: Why does this matter now? What's the cost of not doing it?
Measure: How will you know it worked? What's the observable outcome?
Answer those from real conversations, not assumptions. The frame you set determines the story you can tell. You can only narrate what you set out to collect.
Build Evidence, Not Impressions
The most common mistake is treating observation as evidence.
One observation is an anecdote.
Two is a coincidence.
Three is a pattern.
You can't tell a compelling story about what users need from a single memorable session, you need enough structured data to see the shape of something repeatable.
For qualitative capture, I use the 4Ls:
Like — what's working
Lack — what's missing or falling short
Love — what they'd protect at all costs
Long for — what they wish existed
When the focus is internal, team retrospectives, coaching sessions, stakeholder feedback, there's a fifth:
Learned — what changed in how you're thinking
The 4Ls aren't a replacement for research methods. They're a structured way to accumulate qualitative signal across sessions so patterns become visible instead of staying buried in notes.
Quantitative data tells you what's happening. Qualitative tells you why. Neither works as a standalone decisioning system. The story that moves people is built where they confirm each other: where the number points to something, and the observation explains it.
The Portfolio Arc Most Designers Are Missing
This logic applies directly to how you present your own work. Most designers treat their portfolio as a collection of finished deliverables. It should be a set of stories built from structured evidence. You don't have to guess what narrative to tell, because you built it.
The arc I use with clients:
Role — your position, scope, and the context of the project
Customer — who you were designing for and what their world looked like
Challenge — the specific problem the customer was facing, from their perspective
Approach — what you did to address it, and why that over other options
Outcome — what you set out to achieve versus what actually happened
Wrap-up — a brief summary that reinforces your key points
Strategic question — a reflection that shows you're still thinking, not that the work is closed
The wrap-up matters more than most designers realize. In an interview, your listener may have drifted by the time you finish. A brief restatement of the outcome and what it meant gives them a way back in. In an online case study, it's often the first thing someone reads when the reader scrolls to the bottom before they decide whether to invest the time.
The strategic question works differently depending on context. In an interview, it's a question directed at the interviewer: one that surfaces a gap on their team and positions your experience as the thing that fills it. Done well, it helps an interviewer articulate what they're actually looking for (which they don't always know going in). In a portfolio, it's quieter: a line that shows you're still learning from the work, without stating it so directly that it becomes a disclaimer.
The same arc scales to your resume, your case studies, and how you talk about your work in any context. The story is already there. The structure is what makes it reusable.
AI Doesn't Change the Need for Evidence Systems
When AI can generate a polished case study from a two-sentence brief, the differentiator isn't the output. It's what you feed it.
If you've been capturing structured evidence throughout your work, you have material no one else has, real observations, named patterns, a defined frame that was set before the project started. That produces a story worth telling because the inputs are real.
If you've been working from impressions, AI will generate polished impressions. The output will look credible. The story won't hold up when someone asks a follow-up question.
Build the system before you need the story. The story will be there when you do.
