The team adds to this list as you identify new situations of interest going forward, so don’t be too concerned that it be absolutely complete.

Assign two to three people to each storyboard; run multiple storyboard teams in parallel if you have enough people. Assign storyboard cases to each team so they are all working on a different case.

The first thing each team does is set focus for their storyboard. They harvest all the data they can to support their case. Identify and walk parts of the Affinity that address issues important to the case; identify and review the parts of the consolidated models that are relevant.

Collect any sequences or parts of sequences to suggest an order for the storyboard; reference the Day-in-the-Life Model if the sequences don’t cover your case. If your design envisions a new way of living or working that people don’t do now with technology, you should still have data on how they do the practice manually. Our travel vision, for example, envisions an Idea Collector to collect ideas and notes about things to do—something that doesn’t currently exist online. But people do make notes about events they’re planning; they do research online for various purposes; they collect pictures and save stories; and many do scrapbooking in paper. Sequences describing these activities will suggest overall structure and specific issues to consider in doing the new design. Use them for storyboarding.

When collecting issues, it’s most effective to give each person a model or piece of Affinity to look at and have everyone review the data in parallel, collecting issues as they go. Then the storyboard sub-team can get back together and make one list of all issues pulling together what everyone found.

If your team is not familiar with modern interaction designs and ways of structuring product interfaces across multiple devices, this is also a good time for them to review and learn from your interaction designers. You might look at well-designed products that support the same activity or a similar activity to learn how they are structured. (See Chapter 15 for more on how to do this.) With that knowledge in hand, the storyboards will reflect better initial design knowledge—the team will want to visualize the interface, so they should have some good examples to help them.

The next step is creating a more detailed storyboard vision focused only on the one scenario to be storyboarded. This should take 30 minutes to an hour, no more. Take the initial vision, as captured in the product concepts and elaborated in the Cool Drilldown, as a starting point. Now the sub-team creates a more detailed vision using the Visioning workshop process: talk through how users will handle the particular case the team is working on, given the new inventions from the vision. One person takes the role of pen and draws the design as the team tells the story together. Because the team is now focused on working out one particular case, the visioning is lower level and adds a lot of detail that the original vision didn’t go into. It identifies and resolves problems the original vision never considered. It considers how interfaces might be structured to present function and content. So the sub-team will expand and add on to the original vision but make sure that they stay true to it. They can elaborate on it, fix problems with it, and work out the details, but they shouldn’t go off and do an alternative vision of their own or make up a new product concept that the whole team hasn’t bought into.

The storyboard vision should include rough sketches of user interfaces as they come up in the story—don’t obsess over them, but make sure they reflect modern design approaches. If your storyboard vision is all text, you’re thinking in terms of functions and lists, not in terms of holistic life practice. Or you may be listing high-level user intents that you want to support without ever saying exactly how you’ll support them. Such visions will not jumpstart the structural thinking that will be needed next. But don’t just draw user interfaces either—keep the people and their actions in the picture. You need to include all the human activities and their context to see how your product will fit in.

You are using the user interface sketches to help drive your thinking. You are not designing the user interface at this point, but it’s very hard to think about what the new practice will be without drawing out what the user will see. So assume you will be able to ship a modern interface and incorporate UI sketches as you need them, but do not try to be complete or thorough. Do not worry about consistent layout across storyboards, consistency of function, or details of interactivity. Just capture enough user interface elements to illustrate how the product supports what the user wants to do at each point. Consistency and standards conformance will come later. But you should be envisioning a specific device at each step, and you do need to consider the limitations of that platform—don’t sketch a complicated user interface with lots of parts and then claim it’s used on a smartphone. Make sure that it’s clear what the device is on the storyboard.

Do, however, worry about consistency of action and intent. Does the user want to do the thing you’ve envisioned for them? What questions will they naturally be asking at each point? Do they know what action to take next? How? What guidance will lead them through the activity—and through the use of your product? As you go, you’re likely to come up with additional scenarios that need to be worked through. Don’t do it now—add them to your list of cases and deal with them on their own. It’s often useful for the first storyboard you do to be the “happy path”—everything works out simply for the user. But after that, it’s like any story—stories that are only happy tend to be boring. Think of all the difficult, annoying problems that could occur—that you’ve seen in your user data. Roll those into your storyboards so that you’re always working on an interesting problem.

As the team visions each scenario, they should continually refer back to their consolidated user data. Look for overall structure, distinct strategies people follow, specific situations that need to be handled, intents the user cares about, core motivations or identity elements you need to support, and breakdowns that you can overcome. Make sure you’ve thought about mobile device use and design for use in moments of time. Check the activities of the sequence—either they address a primary user intent and you should keep them coherent in the storyboard, or they are driven by current technology and you can justify taking them apart. The storyboard vision is likely to be more sequential and linear than the initial vision, and that is okay.

In practice, we find teams often forget to keep touching base with the user data. Try not to be one of these teams. It really is best if you keep yourself grounded in the real issues of the user. But if you get to the end of your storyboard vision and you’ve done what we said not to do, go back and use the consolidated user data as a cross-check—walk through the models looking for intents and breakdowns you missed, strategies and situations you don’t support, and mismatches in how you’re supporting the task and how the users think about it.

Once the sub-team is happy with their storyboard vision, they can draw storyboard cells on half sheets of paper. Do this in parallel, letting each sub-team member do cells for a different set of steps from the storyboard vision—all the important decisions have been made, after all.

Use the storyboard cells to illustrate the story of how this life activity is done. Each cell captures one piece of the story: an interaction with a screen of the user interface, with another person, or with a device; or it shows what the system has done for the user behind the scenes to make the next step possible. Try to fill up the storyboard cells comfortably. Cells which are stuffed with too much detail suggest you’re diving down into design details prematurely. Cells which are too bare suggest you’re not really spelling out (or, likely, thinking through) the real process.

Remember that being complete is not the goal at this time. You need enough storyboards to address the central cases of the system before you can start the User Environment Design. Then you will alternate between storyboarding, User Environment Design definition with associated Interaction Patterns, and iteration with the user. Working with the user may reveal more cases you must consider so just do enough at first to guide the product structure and overall approach.

In a storyboard review, each sub-team presents their storyboard in turn. This is actually the first design review in the process—and that means critique. In art or design schools critique is part of the culture, but not everyone has had that experience and we find that no one really likes the process whether or not they have that background. So the first response of the team is appreciation

Once you acknowledge the work, run the review. One member of the sub-team stands up and talks through the storyboard, cell by cell. The rest of the team listens respectfully, asking questions, and making suggestions without a hint of judgment—a challenge for us all! Valid comments include:

The storyboard should be able to stand on its own when read by an individual without narration. Part of the review is to be sure enough drawing and information is in each cell so that when the team returns to it nothing will be forgotten. So during the review, one sub-team member narrates and one captures issues and adds detail to clarify—even noting where to add cells, if needed. But this is not the time to discuss extensive redesign or changes—write a note and send the sub-team back to resolve the issues. A storyboard review will take 20–30 minutes depending on the length of the storyboard. Remember, you are listening and writing down issues and design ideas, not discussing except for clarification.

At the end of the review, the sub-team has a storyboard covered with sticky notes. Usually, it’s best to just let them go back and deal with the notes and go forward with the process without another review. But if there are a lot of significant issues, it may worthwhile for them to rework the storyboard and then bring it back to the whole team to review again. But this should be rare—beware getting yourselves caught in multiple reviews. Remember you are on the way to test. Once represented in a product mockup, you will see if your ideas work for the user, the real last word on the design.

This review is internal to the team to double-check the work and ensure an agreed-upon direction. But the storyboards, once cleaned up after the team review, are a good way to share the direction of the redesigned practice with stakeholders. This is especially important when designing for internal users who want to have a say in how you are changing their lives. So do another review with stakeholders and get their feedback. This can help you anticipate resistance to change and may challenge or refocus what you are planning so that it can be more effective. Storyboard reviews are easy to do remotely by taking pictures of the cells and putting them in a slideshow. But consider your population—if presentation will matter, draw up the storyboard nicely.

Storyboards ensure the new design accounts for the context of use. But the context is not just the task being supported, or how features are structured and grouped in a product; the context that matters is the overall life of the user and the way any activity fits into that life. Storyboarding brings this context into focus for the team during the detailed design process. It lets the team work out all the scenarios, keeping them coherent with scenario-based reasoning. With core storyboards in hand we are ready to decide how to best structure the system to support them.