Narrative-First Design is a practice I run with every crossfunctional team I work with at Back Market — for aligning on the user story before any design work begins, not to document intent, but to surface adoption blockers while changing direction still costs an afternoon, not a sprint.
I started running this workshop after noticing that the hardest post-launch problems — low activation, late pivots, features that did exactly what the brief said but not what the user needed — were almost always things the team could have named together in a room before any design began.
Teams that ship features nobody uses usually had alignment. They had PRDs, kickoffs, review sessions, Slack threads. What they didn't have was a shared, user-centred story that everyone — PM, designer, engineer, marketer — had genuinely agreed on before any work began.
Narrative-First Design replaces the assumption that a requirements doc is the same thing as a shared understanding. It isn't. A requirements doc tells you what to build. A narrative tells you why anyone would use it — and forces the team to answer that question before committing to a direction.
The centrepiece of the practice is a workshop structured around seven narrative questions — drawn from classical story structure, applied to product features. Every question has a job. Together, they produce a complete picture of who the user is, why this feature exists, and where it could fail.
In classical story structure, the crisis is the moment when the protagonist faces the obstacle that could defeat them. In product design, it's the moment when the user faces the friction that could stop them adopting the feature.
Teams that skip this question tend to find the answer later — in user research post-launch, in support tickets, in low activation rates. The Crisis plot point makes adoption friction the subject of explicit conversation before a single pixel is drawn.
The Crisis sits after Rising Action but before the Climax — which mirrors where adoption friction actually lives in the user journey. The feature has been introduced, the user understands what it is — and now they have to decide whether to change their behaviour. That moment of decision is where most features lose users. Designing for it requires naming it.
Common crisis answers: "The user doesn't trust the data." "The workflow adds a step they weren't doing before." "They need to convince their manager before they can act." Each one produces a different design brief — and none of them would have come from a PRD review.
The workshop produces a single elevator pitch in a fixed format. It's designed to be short enough to remember, specific enough to be useful, and portable enough to travel across Slack, Figma files, and stakeholder decks without losing meaning.
This sentence becomes the North Star for the feature — pinned in Figma, referenced in PRD reviews, used to gut-check design decisions throughout the project. If a proposed UI change can't be justified against it, that's a productive conversation to have.
Every project has a moment when the brief turns out to be incomplete. The framework's job is to make that happen in a one-hour workshop — not in QA, and not after launch. Here are three times the Crisis point changed what got built.
Two blockers emerged — and they needed two different features.
The workshop surfaced two distinct adoption barriers that had been treated as one problem. Blocker one: sellers couldn't see their performance clearly enough to act on it — the reporting didn't exist. Blocker two: the timing of deal information didn't fit sellers' sourcing planning cycles — even good reporting would land at the wrong moment. These weren't the same problem. Treating them as one would have produced a single feature that half-solved both.
Complete plot points for this example would be included here.
Example 2 content to be added.
Example 3 content to be added.
The practice only works if everyone is in the room — PM, designer, researcher, marketer. The output belongs to the team, not to a single owner. That shared ownership is what makes the elevator pitch durable across the life of a project.
A case study where narrative framing shaped every major design decision — from user targeting to information architecture.
Read the case study →