18 Comments

Summary:

It’s not uncommon for designers to confuse a beautiful looking product with one that works beautifully. A great technique for creating smarter, better products is to approach them using story-centered design.

Screen Shot 2013-04-14 at 6.10.26 PM

One of the biggest flubs that product teams make is confusing designs that look great with designs that actually work well. It’s a simple mistake, but it can have grave consequences: If your product doesn’t work well, no one will even care how it looks, after all.

The best way I’ve found to get 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 every 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 on what really matters: how their product finally works.

Designs shouldn’t be blueprints

I’ve observed that teams often like to walk through UI designs as they would a blueprint – showing where each element belongs on the plan. Each screen shows how the product might look in a different situation, but the screens are not connected in any way. The problem is that when designs are presented this way, you’re only building an understanding of how the product looks. You’re not focusing on how the product works, and you’re not simulating 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-centered design. They begin by crafting stories that show how customers interact with a product, and only after they’ve accomplished that do they design screens as a way to tell that story of interaction.

The process of designing by story

In story-centered design, teams critique work by looking at dozens of sequential mockups that function like frames in a filmstrip (see the photo above). Designers present every sentence the customer reads, every action they take, and every screen that system generates in response. The designs follow a customer from an initial trigger all the way through completing a goal, and they show how the design supports every step in that flow. I’ve coached many startups through story-centered design exercises and seen these techniques work for mobile apps, marketing websites, analytics dashboards, enterprise IT and beyond.

Here’s an actual example of what I’m talking about.

story-design-whiteboard

For engineers, this should sound familiar. The core of story-centered design is the same as test-driven development. Only instead of writing tests to exercise our code, we’re creating stories to exercise our designs. Just like test-driven development, story-centered design can have an incredible impact on a team’s execution speed and product quality.

Storytelling step-by-step

  1. Whiteboard stories Start design projects by whiteboarding the customer interaction with your team. Draw a bunch of 1-foot sized boxes on your board, then create a story by filling in the boxes with each small interaction the customer makes with your product. Draft critical pieces of copy together. Show each place users will tap or click (again, like the image above). Creating it will take a while, but once the team agrees to the story the rest of the design process will go much faster, with less churn and waste.

  1. Change your tools  Most design tools were made for creating posters or books, so they don’t give you the tools needed to design interaction stories with dozens of frames. So ditch Photoshop early on, and pick up a tool like Keynote, OmniGraffle, or Fireworks that support multiple pages and helps you focus on designing the end-to-end flow.

  1. Never critique single screens It’s a big red flag if someone sends just one or two mockups for review. Make sure your team is always reviewing full stories. If you’re presenting in-person, print each screen on paper and lay them out across the room. This way everyone can see both the overview and the details on each screen. If you need to send designs over email, record a quick screencast video that shows how the screens come together into a story.

Why story-centered design works so well

It simulates the user experience  Story-centered design forces us to ride along with customers through every single step. That gives the entire team (designers, engineers, CEO) a system for making design decisions based on how people will actually experience the product.

Teams spot problems earlier Because stories add a time dimension, they highlight all sorts of design mistakes 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 that have unnecessary steps and dead-ends get noticed and fixed more quickly. All these small details add up to better usability and user engagement.

It clarifies design goals up-front When teams start by designing stories, it forces everyone to come to agreement on the design goals before working out the details. That’s helpful because after designers have spent hours on detailed UI mockups, critique will be narrowly focused on whether the designs accomplish pre-set and understood goals.

It’s science!  Well, sort of. Thinking through how a customer goes from initial trigger (like an email or push notification) all the way through to finishing a goal maps fairly well to BJ Fogg’s Behavior Model of Triggers, Motivations, and Ability. Stories make it easier to check that you have all these elements in place to encourage user behavior.

It speeds up everything else  Stories can often be reused by other parts of the team. Mockups created for showing a story can be repurposed into a quick clickable-prototype for user studies. The same story can be used to build a funnel analysis, which helps us find out whether users are making it through that story in the live product. And the QA team can run through key stories to validate each new release.

(GigaOM will be focusing on experience design at their RoadMap conference in November in San Francisco).

Braden Kowitz leads the Google Ventures Design Studio. Follow him on Twitter @kowitz or through his team’s blog Design Staff.

Have an idea for a post you’d like to contribute to GigaOm? Click here for our guidelines and contact info.

Photo courtesy Braden Kowitz.

You’re subscribed! If you like, you can update your settings

  1. Katie Fehrenbacher Sunday, April 14, 2013

    Awesome piece!

  2. A hint from the dark site:
    Meaning is a path through data

    Means if one wants to create meaningful SW one has to think about sequences(flow), doesn’t matter design or SW engineering. If one thinks about tests in engineering one can easy think in categories, which leads to the feeling of stop and go SW no matter which design sits on top. Case in point iOS.

  3. David H. Deans Sunday, April 14, 2013

    Brandon, thank you for sharing this insightful perspective.

    I’ve not previously considered the benefits of using stories within the development process. It’s yet once more example of how we humans extract context from storytelling. Very enlightening.

  4. David H. Deans Sunday, April 14, 2013

    My apology, of course I should have said “Braden”

  5. Steve Ardire Sunday, April 14, 2013

    > The best product designers practice story-centered design. They begin by crafting stories that show how customers interact with a product, and only after they’ve accomplished that do they design screens as a way to tell that story of interaction.

    Spot on !

  6. Brent Brookler Sunday, April 14, 2013

    Great article Braden. We’re close to launching Flowboard at http://flowboard.com, it might work well to build and share these interactive stories. It supports clickable links and multiple screens (pages), and you can import all kinds of media.

  7. I think Ronald was perhaps saying something similar, but this approach still sounds too UI centric. The first exercise should use something like sequence diagrams to flow out the user and system behaviors, then layer on the UI as this approach suggests. If you’ve ever built a really complex application, you’ll have learned that focusing on UI too soon means mistakes, even with an approach like this.

  8. Nicholas Paredes Monday, April 15, 2013

    Great article! Your process is certainly valuable. I believe it highlights the technology discussion perhaps even more than the design discussion. In my current role, we certainly have discussions similar to this, framed by sprints.

    I tend to use Axure as a prototyping tool. Designing interaction is different than designing visuals. Often I find the flow incongruous and return to remove the extraneous. Prototypes help to visualize the feel of the app. A nice thing about Axure is being able to continually Share the prototype and interact with it on device.

    Another note on Axure is the ability to link wires to stories in tools like Jira, and use them throughout the process into QA.

    Sorry to have focused so much on development! The story model is insightful.

  9. This is a joke, right? Late ‘April fools’ I hope. Nonsense!

  10. “story centered design”?

    Commonly known as “scenario” in system analysis

    1. Actually Thomas Erickson presents a nice argument trying to differentiate scenarios from stories. According to him, scenarios are one order of abstraction higher that stories. Stories are ground truths discovered from the field. Imagine your friend telling you why he was late to a meeting and then launching in to a “how I fixed a flat tire” story. http://www.pliant.org/personal/Tom_Erickson/Storytelling.html

      There is also a book on Story telling in UX, if folks are interested.

Comments have been disabled for this post