Storyboards, Scenarios, Design Personas

“I almost always begin design by talking with users. Initially, my goal is simply to collect people’s stories. I believe that the stories people tell about what they do and how they do it contain information vital to designing good interfaces. Stories reveal what people like about their work, what they hate about it, what works well, what sorts of things are real problems.”

Design as Storytelling; Thomas Erickson; Apple Computer, Inc.

Storyboards use little detail to communicate an idea. Developing a persona moving through a scenario helps the design team bridge the contexts of development and use. Patterns of behavior in the context of social settings gain a stake alongside functional requirements and demographic abstraction. And on a simpler level the storyboard is ideal for instructions and illustrating simple interaction.

I first became aware of what these techniques could bring to the design process while troubleshooting a mystery problem. The product was a threaded sensor and receptacle cell. One company engineered the cell, another the fragile sensor. I didn’t even need to see the parts to visualize the same scenario you have probably formed on your own.

When customers threaded the sensor into the cell, neither part stopped the sensor from being crushed against the cell bottom. Once confirmed, it took little time for me to develop a stop ring which gave the user feedback before damaging the sensor. As brilliant as each engineering firm was, and as simple as what are essentially two threaded parts, neither sought feedback on user interaction.

lightbulb profile

Persona design falls far short of its potential without scenario design and walkthroughs. Only putting the personas into action bridges the contexts of use and implementation.

It’s easy to reduce techniques like storyboarding personas and scenarios to items to be checked off some list. Until you find a famous maker’s energy–saver lightbulb (designed for outdoor use) won’t turn on. It seems the bulkier profile keeps the fancy bulb from making electrical contact with some outdoor fixtures. Where the narrow neck of old bulbs allowed the bulb to pass further into the fixture, standard length threads were a fraction short for the new design. Completely different industries and technical factors but the same design problem: Context.

Example Scenario

Constance detects an alarm indicating an outage of an Internet network backbone facility or element (impacting multiple customers). With one click, the [developer product] equipped internet technician contacts:

  • FR/SMDS “host/stub” circuit: LEC or Interexchange carrier
  • DS1/DS3 backbone circuit: LEC or inter-exchange carrier, systems and Internet Telecom Department (if necessary)
  • Internet router/network equipment: Internet systems group
  • Dialup lines: LEC (and inform Internet help desk of the outage so that they are aware and can update systems status message)

Trouble Ticket window automatically opens, where Contstance already sees a pointer to the hop script activity and Failure Alert type. With the preliminary data entry done automatically, Constance can concentrate on logging the contact response activity.

Constance and the vendor technician determine if DNCC sees LMI on line and PVC is active. With another hop script, Constance can initiate a rebuild of PVC by DNCC (Frame Relay/SMDS). The script used to stop here. Constance modified this [script name type] so the trouble log is updated with the action and rebuild status. (Come review time, Constance will use the usage statistics of his modification in the library module to prove he deserves a promotion.)

The developer’s intelligent scripting will immediately escalate to a stage 2 alert if the trouble ticket hasn’t reached [resolution event] stage or 15 minutes time has elapsed. Unresolved escalated alerts [screenshot] appear on the desktop of Stanley and Dan. Their supervisor Hagar, now off–duty, will only be alerted at stage 3 escalations.

Elastic Users, Default Personas

Personas can help you question basic assumptions, that is the real power of the tool. Most sites build to personas, whether they know it or not. These “default personas” are erroneous; unbacked by user interviews or observation. Consequently business sites are built for an industry insider or employee, not likely customers looking for solutions.

Applications are built to the specifications of users who resemble the development team all the time. It is completely possible to reverse engineer a default persona from the assumptions built into products, software and sites — even when the development effort never used the technique. What that default says about the developer’s preconceptions can be telling.

In other words, having what you prefer to believe come out of a figment of the imagination’s mouth isn’t a persona, but there is a serviceable term which does describe what’s going on.

Making Sure Solutions Go Where The Problems Are

In most cases, no one on the design team has talked directly to users to find out who they are, so designers come up with an idea of a user type. The resulting personas are like the designer’s imaginary friends.
Persona Non Grata by Dan Saffer

Lacking use in context, personas degenerate into a creative writing exercise where the elastic user adapts to accommodate the developer’s implementation model. Should requirements change, these “imaginary friends” are accommodatingly supportive and understanding. Far more companies not using personas for information work default to these fictional user types for validation instead.

Imaginary friends never go to five competitor sites before yours, but well constructed user personas do. Imaginary friends don’t use different keywords on search engines than the webpage is optimized for — personas can. Imaginary friends don’t tighten the threaded parts your company engineers until they hear the crunching sound of crushed glass, but personas explore contingencies. That’s why scenario design is just as important as persona design for making sure solutions go where the user problems are. And storyboarding is the tool for scenario design.

The point of the storyboard is to tell a story. Compelling stories have human situations (including dilemmas), human actions and interactions. If the dilemma isn’t compelling and you can’t empathize with the characters (personas) expect desirability to suffer. In product design it is known as the purpose, in story design it’s the hook.

A stakeholder so hooked will sustain interest through the fuzzy front end of the idea stage. The hook can inspire a project champion. After project start, being part of the story can keep projects as collaboration, rather than parts thown over walls between disciplines or deparment silos. The team can better rank features from the customer standpoint and view groups of features working together as the singular product behavior users do.

Should the design be scaled back or tradeoffs made, factors motivating buyers remain. Product qualities users recommend to others remain. So there’s no need to call the product a solution. Users will realize the product solves their problem just like a lightbulb going on.


This entry was posted in Conceptual Design, Use Cases - Driven Requirements and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s