Perhaps no elicitation technique has been subject to as many interpretations as has "storyboarding." Nonetheless, most of these interpretations agree that the purpose of storyboarding is to gain an early reaction from the users on the concepts proposed for the application. In so doing, storyboards offer one of the most effective techniques for addressing the "Yes, But" syndrome. With storyboarding, the user's reaction can be observed very early in the lifecycle, well before concepts are committed to code and, in many cases, even before detailed specifications are developed. Human factors experts have told us for years that the power of storyboards should not be underestimated. Indeed, the movie industry has used the technique since the first flickers on the silver screen.
Effective storyboarding applies tools that are both inexpensive and easy to work with. Storyboarding
Is extremely inexpensive
Is user friendly, informal, and interactive
Provides an early review of the user interfaces of the system
Is easy to create and easy to modify
Storyboards are also a powerful way to ease the "blank-page syndrome." When the users do not know what they want, even a poor storyboard is likely to elicit a response of "No, that's not what we meant, it's more like the following," and the game is on.
Storyboards can be used to speed the conceptual development of many different facets of an application. Storyboards can be used to understand data visualization, to define and understand business rules that will be implemented in a new business application, to define algorithms and other mathematical constructs that are to be executed inside an embedded system, or to demonstrate reports and other hardcopy outputs for early review. Indeed, storyboards can and should be used for virtually any type of application in which gaining the user's reaction early will be a key success factor.
Basically, a storyboard can be anything the team wants it to be, and the team should feel free to use its imagination to think of ways to storyboard a specific application. Storyboards can be categorized into three types, depending on the mode of interaction with the user: passive, active, or interactive.
Passive storyboards tell a story to the user. They can consist of sketches, pictures, screen shots, PowerPoint presentations, or sample outputs. In a passive storyboard, the analyst plays the role of the system and simply walks the user through the storyboard, with a "When you do this, this happens" explanation.
Active storyboards try to make the user see "a movie that hasn't been produced yet." Active storyboards are animated or automated, perhaps by an automatically sequencing slide presentation or an animation tool or even a movie. Active storyboards provide an automated description of the way the system behaves in a typical usage or operational scenario.
Interactive storyboards let the user experience the system in as realistic a manner as practical. They require participation by the user in order to execute. Interactive storyboards can be simulations or mock-ups or can be advanced to the point of throwaway code. An advanced, interactive storyboard built out of throwaway code can be very close to a throwaway prototype (discussed in a later chapter).
As Figure 12-1 shows, these three storyboarding techniques offer a continuum of possibilities ranging from sample outputs to live interactive demos.
Indeed, the boundary between advanced storyboards and early product prototypes is a fuzzy one.
The choice of storyboarding technique will vary, based on the complexity of the system and the risk of the team's misunderstanding of what the system needs to do. An unprecedented and innovative system that has a soft and fuzzy definition may even require multiple storyboards, moving from passive to interactive as the team's understanding of the system improves.
Disney's Snow White and the Seven Dwarfs, the first animated movie ever produced, used storyboards, and they are routinely used as an integral part of the creative process in movies and cartoons. Virtually all movies, animated features, and cartoons start out with storyboards. They represent the raw creative input that is used to develop the characters and the story line.
In software, storyboards are used most often to work through the details of the human-to-machine interface. In this area, generally one of high votality, each user is likely to have a different opinion of how the interface should work. Storyboards for user-based systems deal with the three essential elements of any activity:
Who the players are
What happens to them
How it happens
The who element defines the players, or the users of the system. In a software system, as we discussed earlier, the "who" are such players as users, other systems, or devices—the actors that interact with the solution system we are constructing. For users, the interaction is typically described via user input screens or data entry forms, outputs such as data or reports, or other types of input and output devices, such as buttons, switches, displays, and monitors. For devices and systems, interaction will be performed via a software or hardware interface, such as a communication protocol or motor controller drive signal.
The what element represents the behavior of the users as they interact with the system or, alternatively, the behavior of the system as it interacts with the user. The how element represents the states that the player or the system assumes during the interaction.
For example, we did a storyboard for an automated-vehicle amusement park ride.
The who represented the guests who ride on the vehicle.
The what represented the behavior of the vehicle as it provided various events for the guests.
The how provided further descriptions of how this interaction happens—events, state transitions—and described both the guest states (surprised, scared) and the vehicle states (accelerating, braking, unloading).
The tools and techniques for storyboarding can be as varied as the team members' and the system users' imaginations will allow. Passive-storyboarding constructs have been made out of tools as simple as paper and pencil or Post-It notes. More advanced passive storyboards can be built with presentation managers such as PowerPoint or Harvard Business Graphics. Passive and active user interactive storyboards have been built with HyperCard, SuperCard, and various packages that allow fast development of user screens and output reports. Interactive storyboards can be built with a variety of specialty software packages for interactive prototyping, such as Dan Bricklin's Demo It. Tools such as Macromedia's Director and Cinemation from Vividus Corp. can be used to create more complex animations and simulations.
In a simpler example, at RELA, Inc., one team member also dabbled in cartooning on the side. At the concept stage of a project, he would simply sketch a half dozen or so simple cartoons that showed the product in its typical use or various aspects of the product's interface. This was a quick and inexpensive way to gain a reaction from the potential users. Also, the cartoonlike nature of the output avoided some of the potential of problems of storyboarding, as we'll see later. Unfortunately, no other cartoonists were around when the designer left the company, leaving us to find alternative storyboarding techniques!
In our current efforts, which are focused mostly on ISV applications, we get along quite nicely by using only PowerPoint or other common desktop presentation managers, in combination with sample screen shots built by the same tools used to build the GUIs in the application. Interestingly, the greatest breakthrough in storyboarding technique may well have been the simple addition of the animation capability to PowerPoint. Suddenly, our ability to express dynamics and interactivity increased by an order of magnitude.
Storyboarding is a powerful technique designed to gain early user feedback, using inexpensive tools. As such, storyboards are particularly effective at addressing the "Yes, But" syndrome. They also help address the "Undiscovered Ruins" syndrome by eliciting immediate user feedback as to what the system "doesn't appear to do." But as with any technique, certain caveats apply. Here are some tips to keep in mind as you practice your storyboarding technique.
Don't invest too much in a storyboard. . Customers will be intimidated from making changes if it looks like a real work product or they think they might insult you, a particularly difficult problem in some cultures. It's OK to keep the storyboard clunky and sketchy, even crude. (See the storyboarding story at the end of this chapter.)
If you don't change anything, you don't learn anything. . Make the storyboard easy to modify. You should be able to modify a storyboard in a few hours.
Don't make the storyboard too good. . If you do, the customers will want to "ship it." (In one real-world project, we suffered for years supporting an Excel/VB product that was never intended to be more than a storyboard.) Keep the storyboard sketchy; use tools and techniques that have no danger of making it into the field, especially for storyboards that are coded. (Hint: If the application is to be implemented in Java, write the storyboard in VB.)
Whenever possible, make the storyboard interactive. . The customer's experience of use will generate more feedback and will elicit more new requirements than a passive storyboard will.
In this chapter, we learned about a very simple and inexpensive technique for requirements elicitation. In a sense, a storyboard is anything you can build quickly and inexpensively that will elicit a "Yes, But" reaction from the user.
We can say with confidence that there has never been a time when we didn't learn a lot from a storyboard, and there has never been a case in which we left the storyboarding exercise with exactly the same understanding with which we entered it. So our advice to the development team is to
Storyboard early.
Storyboard often.
Storyboard on every project that has new or innovative content.
By so doing, you will get the "Yes, Buts" out early, which in turn will help you build systems that do a better job of meeting the user's real needs. And perhaps you will do so more quickly and more economically than you have ever done before!