According to the Wikipedia, Storyboard is:
A storyboard is a graphic organizer in the form of illustrations or images displayed in sequence for the purpose of pre-visualizing a motion picture, animation, motion graphic or interactive media sequence. The storyboarding process, in the form it is known today, was developed at Walt Disney Productions during the early 1930s, after several years of similar processes being in use at Walt Disney and other animation studios.
[...]
Storyboarding is used in software development as part of identifying the specifications for a particular software. During the specification phase, screens that the software will display are drawn, either on paper or using other specialized software, to illustrate the important steps of the user experience. The storyboard is then modified by the engineers and the client while they decide on their specific needs. The reason why storyboarding is useful during software engineering is that it helps the user understand exactly how the software will work, much better than an abstract description. It is also cheaper to make changes to a storyboard than an implemented piece of software.
[...]
The process of visual thinking and planning allows a group of people to brainstorm together, placing their ideas on storyboards and then arranging the storyboards on the wall. This fosters more ideas and generates consensus inside the group.
Watch the following video until 5:55:
Transcription
Hi there, welcome back!
Early on the course, I outlined a design process that favours rapid exploration early on. Now let’s learn how to actually accomplish that.
In this video, we’ll dive into three techniques for rapidly producing prototypes. Over the course of your project, the fidelity of the prototypes that you create is going to increase, and you’ll want to pick tools that reflect where you’re at in terms of the design process, not using stuff that’s too high-fidelity and too time-consuming early on.
So, for example, you might start out by storyboarding, which is the first technique we’ll learn today. That will give you a sense of the tasks and the scenarios you’d like to support. Then you might move on to paper prototypes, and from there digital mockups. Then, if you’re in the web domain, some static HTML. And, only then, get dynamic — add in the database and the other fancy parts.
Picking the right tool for the job helps you focus on the questions that you have at that particular stage of the design process. So, in the video we’re going to talk about storyboarding, creating and testing paper prototypes, and moving on to digital mockups.
One of the easiest mistakes to make in interface design is to focus on the user interface before you focused on the tasks that the interface’s going to support. And, if you got one thing out of storyboarding, the piece to understand is that storyboarding is all about tasks.
Here’s an example from the “Lifealyfics” project team from my Stanford HCI class in the Fall of 2011. They were interested in user interfaces for behaviour tracking, and here are a couple of the early storyboards that they produced.
What’s nice about a storyboard is in just a few panels you can convey what the user interface will help a person accomplish. And a good storyboard is nearly always going to have an actual person in there.
Another thing that you can see in these storyboards is that they communicate flow: Much like a comic strip, it’s showing what’s happening at key points in time.
One of the biggest worries about creating storyboards is that they’d tell me “Ugh, I can’t draw!” But storyboarding isn’t about beautiful drawing; it’s about communicating ideas, and I think that everyone can learn how to visually communicate ideas.
In some ways, bad drawing is actually an asset, because then all you can do is focus on the content.
I said that good storyboards nearly always include a person who’s actually using the interface, and so, to get you started, I’d like to teach you my favourite trick for storyboarding. I learnt this from Bill Verplank. Bill and I taught together at Stanford for several years. And Bill, [inaudible] for generations, has taught people how to draw “Star People”, and it goes like this:
We call it a “star person” because the body of the person is kind of like a star, and you can have them doing all sorts of things, so somebody can be holding something, or they can be reaching up to touch maybe something on a big screen.
You can add any dynamics that you want.
If you need to, you can show where people are looking.
If you want, you can distinguish different people in the scenes — so you can colour them in a little bit, or you can add a sheriff’s badge.
And, when you put it all together, you can get something like this.
These are some images from the storyboarding guide that we’ve linked from your assignment. One of the very first things a storyboard should do is to illustrate a goal. Like in this storyboard, it’s “Let’s check out places in SF!”
You can show how a task unfolds, and here you can see some “star people”, and they’re explaining what they’re doing, so here they’s saying “Here we’re in San Francisco.”
And by the end of the storyboard you’ll want to show how they accomplished what their goal was, or, in some other way, have a satisfactory outcome at the end of the storyboard.
And as a mall shows, even with a really simple visual language, there’s a whole lot you can do to get your point across.
So, storyboards should accomplish three things:
First, it should accomplish the setting: Who are the people involved? what’s the environment? and what tasks are they trying to do?
Next, it should show the sequence: What are the steps that they do to accomplish the task? — Not necessarily what user interface’s exactly where the buttons and widgets are, but what role the user interface plays in helping them get their goal achieved.
And one the the first steps is going to be: What leads somebody to use the app?
In the mall’s example, that began with somebody saying “Let’s check out places in San Francisco!” That’s the springboard that clearly motivates people to go to the application.
And then your app can easily and clearly show what’s the task that the idea you have is supporting.
And then finally, at the end, you’ve got the satisfaction —
How does what motivated them to use the app in the first place, how does that connect to their achieving that in the end of the sequence?
Questions your storyboard can help you think about are:
“What is it that enables people to accomplish, and what need does your application fill?” I really like storyboards for their holistic focus; it enables you to think through how you might support a task without committing to a particular user interface — that’s the magic, and this is especially important when you’re designing as a team, because the idea that’s in your head may or may not be the same as the idea that’s in somebody else’s head.
Or, you may have this great idea, but people don’t know what you’re talking about yet.
Once you’ve got it out on paper and concrete, it makes it much easier for poeple to have common ground, and agree on how to move forward.
When you’re storyboarding, I suggest imposing extremely harsh time limits on yourself, like 10 minutes for a storyboard. It can be easy to try and get everything beautiful even if you’re sketching out with pen and paper, but that’s not the point!
Continues in Paper prototyping