About Our Approach

Q: What does “story-first” get you that other strategic approaches don’t?

A: It saves time and effort.

When you’re designing a complex user experience, your biggest challenge isn’t how to design a particular element, but how to get all of those elements to align—to figure out the overall shape of the experience. You’re dealing with multiple user personas, branching use cases, and an experiences that jumps from one platform to another, which gives you a range of options that practically infinite. A lot of design teams try to solve this by making and iterating prototypes, and there are great tools for doing this: wireframes, user journeys, service blueprints, clickable mockups, video prototypes, etc.

But in our experience, these tools are good for designing specific elements (an app, a POS interaction, etc.), not a complete multi-platform experience. Most are too granular and labor-intensive to let you broadly explore the end-to-end experience without burning up budgets and schedules.

A story-first approach adds another tool to the prototyping toolkit; one that’s quick, flexible, low-investment, and ideal for modeling complete experiences. So while narrative doesn’t replace the tools above, it does make them more effective, by giving design teams and stakeholders a coherent vision, and providing a clear reference point for more detailed efforts later on.

Q: What kind of deliverables can I expect?

A: Whatever’s most useful for your project.

A written narrative can be extremely useful, especially for established design teams who have everything they need except a central guiding story. But depending on the project needs, we can also build on that story to produce a range of other artefacts:

  • Detailed user journeys and service maps

  • Storyboards and video prototypes

  • Wireframes and user stories

  • UX and web copy

  • Testing benchmarks

We also run customised workshops that introduce your team to the principles of narrative-driven experience strategy, and let them practice applying these principles to existing design challenges.

Q: How is this new? Good designers have always been good storytellers.

A: The term “story” means different things to different people. There’s the story of what we discovered in user research, the story of an online ad campaign, the story that this cool picture tells, the story of the luxury experience we just had, etc. “Storytelling” in these contexts usually means presenting ideas and information in a way that makes sense to the audience. That’s a noble and valuable pursuit.

But there’s also a more specific, classical definition of story:

  • it has a clearly identified hero

  • the hero has a goal, and must overcome obstacles to reach it

  • it proceeds from an initial stasis (exposition) to a final stasis (resolution)

  • it hinges on a clear incident that causes the hero to depart from that initial stasis

This may all sound academic, but it’s actually quite important, because stories with this format hook into the human brain in a uniquely memorable, resonant way. And experiences that use this structure are more likely to feel meaningful and satisfying to the user.

Q: Doesn’t a User-Centred approach give you a strong story anyway?

A: In theory, yes. And sometimes in practice, too. A tightly focused app or other touchpoint, designed by a thoughtful, empathetic professional is very likely to have a clear narrative flow. It’s a natural outcome of User- or Human-Centred Design practice.

But as challenges get more complex and design teams diversify, this becomes less automatic. Individual designers can be intensely user-centred about the elements they’re designing, but the user’s story spans numerous elements. So even if each one is expertly designed, with user needs front and centre, there’s a broader narrative that needs shepherding. And in order to create and refine a broader narrative, someone has to own it.


About Narrative Prototyping

Q: Isn’t this the same as scenario planning?

A: We should start by saying: we love UX scenario planning. We’ve done a bunch of it, and it’s a proven, powerful way to examine possible futures.

That said, a Narrative Prototype differs from a scenario in a few key ways:

  1. It’s part of a design process, not a future-proofing exercise. A Narrative Prototype is there to help your team depict what it’s going to create, and how that will impact a user. Scenario Planning, according to the classic texts and talks, is expressly not for planning user experiences, but for imagining possible futures in order to prepare for the unknown. Both are useful, but at different times and places.

  2. It’s explicitly integrative. A Narrative Prototype is a living document, that goes through rounds of revision based on feedback and contributions from designers, users, and stakeholders. Unlike a scenario, it’s an expression of intent and capability as much as external trends.

  3. It leverages traditional narrative structure to create meaning. See “How is this new?” in the previous section.

  4. It’s about the user, not the organisation. The hero of a Narrative Prototype is usually a user or stakeholder engaging with the experience. A scenario is more often about a describing a future situation, and how it impacts the organisation.

Q: But we already do brand storytelling! How is this any different?

A: The hero of a brand story is the brand, and the story’s purpose is to flesh out and animate the history and values that make that brand unique. This is important work, because it aligns marketing efforts by giving them a consistent reference point, and because it gives the customer something to form a relationship with. Finding the right brand story is an act of reflection and insight: you plumb the depths of the brand’s values, its origin, its unique reason for being, and you tell that as a vivid story.

But the hero of a Narrative Prototype isn’t the brand, it’s the user. Its focus is the user’s struggle to overcome a set of challenges. A brand can certainly be present in a Narrative Prototype, but as an ally or guide, not as the protagonist. Finding the right story is an act of empathy with the user, which is then refined through iteration with the design team. A Narrative Prototype is also more conjectural than a Brand Story—it presents an intended future, rather than plumbing the past and present for existing truths.

Q: So you’re talking about User Stories, right?

A: Nope. In UX parlance, a User Story is a short, specific statement that gives developers a target when creating a new feature: “As a user, I want to change the photo on my profile…” or something similarly focused. A complex user experience project might include hundreds of these tiny stories, each driving a small part of a satisfying interaction flow.

A Narrative Prototype, on the other hand, covers an entire user experience from beginning to end. It’s broader, often spans multiple platforms (web, app, in-person, storefront, etc.), and is also used to solicit feedback from designers and developers, before becoming a guide document later on. A well-developed Narrative Prototype is actually a great place to start when it’s time to generate User Stories: when there’s a strong story with a clear progression of actions and interactions, it’s a lot more straightforward to define the individual features that comprise it.

Q: Isn’t this just another way to get hung up in Analysis Paralysis?

A: Not if you have someone in charge of the story.

If the story owner is any good, the narrative they produce will provide clarity that helps get you out of the analysis spiral that often plagues teams facing too many variables.

Q: Isn’t an iterative planning process like this basically the same as Agile?

A: Agile is a great way to build software. It’s also a great way to burn through budget and schedule when used to iterate a multi-faceted user experience.

The heart of Agile is building quickly and then improving, which works well when the cost of updating is relatively low. For an experience with a lot of moving parts—say, a medical or financial tool that spans mobile, web and in-person touchpoints—this gets expensive quickly, and tends to get you a detailed picture of a portion of the experience, rather than a rough picture of the whole thing.

A Narrative Prototype lets you iterate in an Agile-like way, but in a medium that’s lighter weight, and better suited to complex experience planning. It can be as loose or detailed as you need, can integrate dozens of details from various teams, and can be trashed and redone in a few hours. In our experience, it’s a better venue for working out initial structure than jumping straight to code, mockups, or wireframes.

Q: If Narrative Prototyping works so well, why isn’t everyone already doing it?

Short answer: Because designers hate to write.

Longer answer: Design teams tend to favour visual and interactive artefacts (sketches, wireframes, video, etc.) because they quickly evoke specific elements of an experience, and because many creative professionals come from visual backgrounds: graphic design, video production, interaction design, and so on. Because of this, writing is often viewed as a necessary evil. We write emails and proposals, and put copy in our decks and interfaces, but few of us are comfortable crafting long-form narrative about things that haven’t happened yet. It’s a specific skill set, and if you haven’t cranked out a few hundred thousand words of it, it’s drudgery.

But writing, like sketching, is a different tool in well-practiced hands. For someone who sketches frequently, sketching is quick, flexible, and practically effortless. It becomes part of the conversation, not a distraction, and the results are both useful and disposable. Similarly, an experienced writer who knows how to work UX concepts into a coherent story can build one from scratch in a matter of hours, and incorporate new ideas or feedback in minutes.

Plenty of teams use written and visual narrative in their process, but turning it into a prototyping tool requires a level of familiarity and expertise that’s rare in the design world. We’re hoping to change that.