Story Boarding and Wireframes

In the last chapter, we put our personas to work by describing our use cases and flows in scenarios, and how our users will actually interact with our application concepts. Now we layer on additional context by adding visual elements to the textual descriptions. In this chapter we describe the process of storyboarding and then begin building wireframes of the user interfaces.

What is Storyboarding?

When fleshing out an application concept, it's true that a picture (or several) can be worth thousands of words. We are visual creatures and the act of working through drawings and trying variations is critical to designing good user experiences. The "act of drawing (and even seeing others draw) can help us think, and images can speak more powerfully than just words by adding extra layers of meaning." (Source: http://johnnyholland.org/2011/10/storyboarding-ux-part-1-an-introduction/)

The act of translating a process into a set of pictures is nothing new, "the Walt Disney studio is credited with popularizing storyboards, using sketches of frames as far back as the 1920s." (Source: http://johnnyholland.org/2011/10/storyboarding-ux-part-1-an-introduction/) and we all know comic books have been around for some time. What is new is using these storyboards to tell stories related to developing software applications.

Simply the act of translating the scenarios into drawings can illuminate interesting problems, and lead to better feature design and understanding. "You can often learn unexpected things from storyboards, and embedding that context into your design efforts helps keep them grounded in the reality of the users’ lives." (Source: http://uxmag.com/articles/storyboarding-in-the-software-design-process)

Maybe on paper it makes sense to pull out your phone and snap a picture of a meal for a calorie counting app, but when we see a picture of a couple at an elegant dinner and the user awkwardly fumbling with his phone, we might think again. "Storyboarding helps enforce a discipline of thinking in terms of experiential flow. Using storyboards is one way to help keep your mind on the flow and not get lost thinking of the UI you’re designing as an isolated artifact." (Source: http://uxmag.com/articles/storyboarding-in-the-software-design-process)

In software development, storyboarding is the creation of a series of images to represent key points in a user interaction.

Drawing Storyboards

With storyboarding, the rough user interface will start to creep into the images, but the key point to remember is focus on the interaction. You may need to show the surface of a phone, or a computer, or some buttons and clicks, but try to focus on the user and how he or she works with your application, the context surrounding the interaction.

Break Apart Scenarios

For the scenarios you'd like to storyboard, start to break them apart into discreet events. Look for the "verbs" and the "nouns." These will help you narrow in on defining "settings" and "actions" in which your persona engages. Let's take a look at a few of our previous scenarios and break them apart:

Scenario 1

Janet is a busy soccer mom with two kids and lots of responsibilities. She is often on the go and is constantly bombarded with requests for her attention. While she is watching her children's soccer game she runs into a colleague that asks about the reports that are due the following week. Janet knows these are important and wants to jot down something to remind herself of these reports. She takes her iPad out of her purse and launches our Todo application, she types in a message about checking up on the reports and saves it.

Nouns

• mom
• kids
• requests
• soccer game
• colleague
• reports
• reminder
• iPad
• purse
• application
• message

Verbs

• bombarded
• watching
• asks
• jot
• remind
• takes out
• launches
• types
• saves

You may start to see in your head various settings and "props" and also the actions that take place. We can think of settings as areas were action can occur; in this example, even though everything takes place at a soccer game, other action takes place in the "setting" of using her iPad. Let's define these further:

Settings

• Soccer game
• Talking to colleague
• Interacting with iPad

Actions

• Watches soccer game
• Talks to colleague
• Remembers reports
• Takes out iPad
• Launches application
• Enters todo
• Saves todo

Create the scenes

We should see now that the actions will more or less become the frames of our storyboard, and the settings as backdrops. Now it's time to work through each of our actions and create a light representation of that interaction.

When you draw, use a fat permanent marker, like the standard issue "Sharpie Fine Point." Why? Because at this level we don't care about perfect, we care about quick and simple. Don't worry about your drawing ability, don't worry about mistakes. These storyboards start as very rough ideas and are improved with feedback.

You may very well discover as you draw your interactions certain nuances that you missed. This is ok! This is the whole reason we are doing storyboarding, both for you as the one designing and developing the product, and for your users who will learn about your solution easily with a good storyboard.

Wireframing

After you have storyboarded several scenarios you will invariably start to understand the important parts of the user interface. This is where wireframing can come in as a helpful way to "visualize user interface ideas and discuss them with others. 'Fail fast, fail early, fail often' is the mantra here: You get your ideas in front of the relevant stakeholders as soon as possible, gather their feedback and then iterate toward a solution that everyone is happy with." (Source: http://usabilitygeek.com/wireframing-storyboarding-powerpoint-powermockup/)

Wireframes start out purposely rough because how something looks is far less important than the functionality, "we don't want to be going off on a visual tangent as to how that should look." (Source: http://hashrocket.com/blog/posts/survival-tips-for-live-wireframing) "A wireframe will give you sense of elements' placement on the page and relative to each other and which items will get stronger visual treatment, but it won't speak to color, graphics, spacing, or typography, because wireframes don't get into stylistic details they're easier to create and much easier to change." (Source: http://viget.com/inspire/ux-101-the-wireframe1)

Check out the link above for several questions to ask yourself when building out a wireframe. Focus on the interactive elements from your storyboards, we can already see a little of the user interface in one of the frames above. These are clearly important interfaces and may help further define the core of your application. Expand on that. Work through the actions that are specific to your application concept:

• Launches application
• Enters todo
• Saves todo

This can give you a good starting point for user interfaces to design. But also consider other user interfaces not mentioned in the storyboard. Ask yourself "what happens next?" You'll also start to think of all sorts of "other" features that you may want:

• What about a menu bar?
• What about accounts?
• What about logos?
• What about viewing a list of todos?

These may or may not be relevant to your current storyboard, remember focus on the user interaction at hand. Focus on the core of the application and build other features with other scenarios and storyboards.

It can be helpful to use software tools geared toward creating wireframes, and also lending some light level of realism to the designs.

Wire frame your heart out!

The whole point of wireframes is quick feedback and ideation. So make lots and lots of wireframes, experiment, try some wacky ideas. Move content around and work through your storyboards and scenarios to see if things make sense. While we won't cover this in the course of this book, often designers will run usability tests with their wireframes to see how real users interact with these "paper prototypes."

If you and a partner are working on an application and you get into an argument about design, well that's a perfect indication that you both need more information. Brainstorm several wireframes, pick the best two and then provide a group of friends with each wireframe and the goal they are trying to accomplish. This could help you understand which wireframe provides for the best experience. Below is another crack at the Todo app interface, which would you rather use?

What's Next

Our Todo app has come a long way through the planning process, and we are nearing the development stage with a good idea of where our core functionality, features, and user needs lie. Next chapter will focus on breaking our scenarios and wireframes down further into bite-sized, well-defined chunks that can then be developed.