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.
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.
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
- FDDI: LEC
- 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)
A 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
Scenario: Cell phone/scanner
informs the buying decision
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.
- Personas and Storytelling has a simple message. “Personas work because they tell stories.”
- Autistic Social Software explains the default persona software is built for, this reverse engineering is possible through an analysis of design rhetoric.
- Value Scenarios: A Technique for Envisioning Systemic Effects of New Technologies (PDF) “…there is a scarcity of methods which support critical, systemic, long-term thinking in current design practice, technology development and deployment. To address this need we introduce value scenarios, an extension of scenario-based design which can support envisioning the systemic effects of new technologies.”
- Why Personas Are Invaluable for Marketing explains why marketers and copywriters are using personas. And the article Stop Perfuming the Pig: Why “real” marketing is done before the product is created bluntly states what happens without persona based design.
- How to Read People: Preparing to Read should be required reading, before anyone is allowed to conduct a user test. Discussion of guidelines for user observation is about conducting user observation.
- An article explaining how Forth & Towne design uses personas and scenarios for branding. Merging personas and marketing need states are user journeys.
- Gerry McGovern asks Do you make the most common mistake in content management? Suggesting personas for content development puts action behind the words “know your customer.”
- Building a Data–Backed Persona shows how personas are used to give an overview of analytics simply pouring over numbers doesn’t.
- The value of the novel in designing for experience argues against the normal scenario for UX (user experience design) instead favoring pastiche scenarios.
- Cliff Atkinson’s Beyond Bullets blog touts storyboarding as the key to moving beyond PowerPoint’s oversimplistic insistence on bullet points.
Users increasingly choose one brand of product for use at home or work, but another when out with friends. The consumer hasn’t switched, but has two (or more) use profiles or personas they desire the product brand image to support in each situation. One way to design for this behavior is with a personality test for each persona’s need state. The concept design for QuickOrder and Amazon Frucal, allow cellphone users to shop physical, buy virtual perhaps in recognition many shoppers go to bricks then hit the clicks right now. Many companies are working to transition the cellphone into an information scanner. The A key technology to understand is augmented reality. Pocket Bargainfinder is the predecessor to Aura and other cell phone turned scanner technologies. Using Pocket Bargainfinder, a user can try on clothes, glance through a book, soak up the physical store atmosphere …then scan the barcode and find and even order from the cheapest source. ACM paper on why personas can be more engaging than scenarios alone. Taking the “You” Out of User: My Experience Using Personas “Our work with personas increased our awareness of our audience and their varying skill levels and goals when using the application. The use of personas helped move all our discussions about the application, not only those related to the interface, away from the realm of vagaries and into tangible, actionable items.” Details the development of Pyra and Blogger. The Trouble with Scenarios and Personas is, in essence, a scenario cautioning against scenarios and personas as creative writing exercises; unsupported by research or user interviews. “Pay attention. Observe. Reflect. We’re all out in the world we design for. Notice, for example, that people use other communication channels besides their computers. Like the telephone. That if their shopping list is on their PDA, they won’t have two hands free to push the cart. That their homes and offices are full of paper, reminding them to do this and that without requiring them to produce any explicit representation of a “to–do” list. Of course, informal observation is no substitute for real ethnographically–derived inquiry, but it’s a start. Perhaps it should be called ‘feral ethnography.’” The Japanese “three actuals” observation process makes a good complement whenever possible. “A visit to the site about a specific problem not only prevents engineers from becoming detached from the actual process, it often yields insight into a completely unrelated and unforeseen issue, says Shriver.” Go to the actual place, observe actual people, in the actual situation. Consumer behavior researchers like Paco Underhill use three actuals observation techniques fitting the feral ethnography model. “Technically, the user is considered elastic because, conceptually, they become infinitely malleable. The elastic user is a playdough person that is more often than not mashed into the round hole by the programmer. The software might perform all of the tasks it
was required to perform, but more often than not, the same software demands that the user tie themselves in knots to get their job done. Understandably, many people have been left unsatisfied when their software was finally delivered.” Using Persona to Drive Software Design and Customer Satisfaction. A proper methodology, interviewing stakeholders and observing users tends to counteract the elastic user.
The Marketing Scenario: A Reality Check on Your Marketing Strategy forces you to detail the compelling reason customers are going to change their behavior and buy. The process of storyboarding personas acting within business scenarios can create an interdisciplinary communication tool for shared context. Scenario planning tutorials are rare, especially those underscoring the purpose and definition of scenario planning is to develop flexibility of response to uncertainty; not rigid plans which collapse upon contact with reality. In scenario–based design misuse cases and contingency scenarios are used for security applications or child–proof products. Rising Heat My new thermostat was designed by brilliant morons By Virginia Postrel. Anecdotal evidence of customers as abstractions outside the product development process.