Start with the story. Then open Figma.
The launches that hurt most were never the broken ones. They were the ones that worked exactly as built and still didn’t get used. Every time I traced one back, the blocker turned out to be something the team could have named together, in a room, in an hour, before anyone opened a design tool.
So that’s what Narrative-First Design is: a one-hour workshop I run with cross-functional teams to align on the user’s story before any design work begins. Adoption blockers get named while changing direction still costs an afternoon, not a sprint.
Why it exists
Most alignment failures are framing failures
Here’s the uncomfortable part: teams that ship features nobody uses usually had alignment. Everyone agreed on the brief. What they didn’t have was a shared frame for the user’s story, so each discipline filled the gaps with its own version, and the versions only collided at launch.
The three failures it prevents
- Adoption blockers surface too late
- The reasons a user won’t adopt the feature exist on day one. Without a ritual that names them, they surface in the post-launch metrics instead.
- Design decisions detach from user intent
- Without a shared story, decisions get justified against taste, or against whoever argued last. The story gives every decision one thing to be checked against.
- Alignment lives in Slack, not the work
- A thread agreeing on direction just proves a conversation happened. Alignment is when the team can retell the same story unprompted.
The framework
Seven questions. One hour. A story the whole team owns.
The workshop walks the team through the user’s story as seven plot points, in order. By the end there’s a complete picture of who the user is, why the feature exists, and where it could fail.
- 01
What does the user want?
Their goal in their words, not the feature’s description of it.
- 02
Why can’t they get it today?
The obstacle that makes the current path fail, cost too much, or feel too risky.
- 03
What do we introduce?
The feature, told as an event in the user’s story rather than a spec.
- 04
What would stop them adopting it?
The hesitation. The plot point teams skip.
- 05
What convinces them to cross?
The proof or the moment that makes trying it feel safe and worth it.
- 06
What changes in their behaviour?
What they now do differently, and what that demands of the product around it.
- 07
What does success look like?
The observable outcome for the user, and the measurable one for the team.
The key insight
Most teams skip plot point four. That’s where features go to die.
In story structure it’s the crisis: the moment the protagonist has to decide whether to change. In product terms, the feature has been introduced, the user understands it, and now they have to decide whether to change how they work. Most features lose their users right there, quietly, and you can’t design for a moment you never named.
The output
One sentence the whole team can use
The workshop ends with a single sentence assembled from the plot points: who the user is, what blocks them, what we’re introducing, and what changes for them. Short enough to remember, specific enough to argue with.
That sentence becomes the feature’s north star. It gets quoted in sprints and PRD reviews, and it gut-checks design decisions for the rest of the project. When a decision can’t be justified against it, that’s a conversation worth having. And when the sentence itself has to change mid-project, that’s the earliest warning you’ll ever get that the problem has moved underneath you.
For the user who can’t the blocker, we’re introducing the feature so that the change, which we’ll see in the measure.
Filled in, from a real workshop
“For the seller who can’t tell whether the incentive is paying off, we’re introducing a live view of their progress against the target, so that they adjust their prices without waiting for an account manager, which we’ll see in incentive participation.”
In practice
One workshop, two blockers, two features
Running the workshop on a seller-incentive feature, the room had been treating adoption as a single problem: sellers weren’t acting on the incentive. Plot point four split it in two.
Why it works
It’s not a process for designers. It’s a process for teams.
It only works with everyone in the room, including whoever owns the metric. The story belongs to the team rather than to any one discipline, and that’s what makes the decisions hold. Blockers surface in an hour instead of a sprint. Nobody assumes alignment, because you’ve heard the whole room tell the same story.