Why good stories help design great products

One of the biggest mistakes product teams make is confusing designs that look great but don't work well. It's a simple mistake, but it can have serious consequences: after all, if your product doesn't work properly, no one cares what it looks like anymore.

The best way around this confusion is a technique called story-centered design. The idea is to create a series of narrative use cases for your product that illustrate each step in the user's journey through it. I've used this technique with dozens of startups, and it always helps teams move past the surface visual details to make better decisions about what really matters: how their product finally works. 

Designs shouldn't be blueprints

I've noticed that teams often like to walk through UI designs as they would a blueprint - showing what each element belongs to. Each screen shows what the product might look like in a different situation, but the screens are not connected in any way. The problem is that when designs are presented in this way, you only build a better understanding of what the product looks like. You don't focus on how the product works, and you don't simulate how customers interact with it. So when teams critique designs as blueprints, it severely limits their ability to reason through the interactivity of the product.

The best product designers practice story-driven design. They start by creating stories that show how customers interact with a product, and only after doing that do they design screens as a way to tell that interaction story. 

The process of designing on story

In story-centered design, teams work critically by looking at dozens of sequential mockups that function as frames in a filmstrip (see photo below). Designers present every sentence the customer reads, every action they take, and every screen generated by the system in response. The designs follow a client from an initial trigger through the completion of a goal, showing how the design supports each step in that flow. I've coached many startups through story-focused design exercises and these techniques worked for mobile apps, marketing websites, analytics dashboards, enterprise IT and many more.

To engineers, this should sound familiar. The core of story-centered design is the same as proof-driven development. Only instead of writing tests to exercise our code, we create stories to exercise our designs. Like test-driven development, story-driven design can have an incredible impact on the speed and quality of a product. 

Why story-centered design works so well

It simulates the user experience. The story-driven design forces us to drive through every step with customers. That gives the entire team (designers, engineers, CEO) a system to make design decisions based on how people will actually experience the product.

Teams Spot Issues Earlier Because stories add a time dimension, they highlight all sorts of design flaws that teams often miss when viewing their product as just a bunch of screens. Stories make it easier to notice when prompts don't set the right expectations. UI flows with unnecessary steps and dead ends are noticed and repaired faster. All these little details add up to better usability and user engagement.

It clarifies design goals up front When teams start designing stories, it forces everyone to agree on the design goals before fleshing out the details. That's useful, because after designers spend hours on detailed UI mockups, criticism will narrowly focus on whether the designs achieve predefined and understood goals.

It's science! Yeah, sort of. Thinking through how a customer goes from initial trigger (such as an email or push notification) all the way through to completing a target card pretty much adheres to BJ Fogg's Behavioral Model of Triggers, Motivations, and Ability. Stories make it easier to verify that all these elements are in place to drive user behavior.

It speeds up everything else. Stories can often be reused by other parts of the team. Mockups created for displaying a story can be turned into a quick clickable prototype for user studies. The same story can be used to create a funnel analysis, which helps us find out if users are going through the story in the live product. And the QA team can go through key stories to validate each new release.