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 <i>everyone</i> 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:

[Professor Klemmer starts drawing a “star person”]

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!

Once you’ve got a rough idea of what your application’s going to accomplish,

you can start to think about how you’re going to implement that,

and by implement I mean “What’s it going to look and feel like to the user?

What’s the actual user interface is going to be?”

And for figuring out the user interface at an early stage,

the very best technique that I know is to use paper prototyping.

Paper prototyping is exactly what it sounds like:

You’re going to make a mockup of the user interface, and, instead of doing it on the computer,

which can take a lot of time and encourage you to try to get it beautiful and exact,

you’re going to use paper, Post-It notes, and markers, to sketch things out really quickly.

Here’s an example, it’s again from the “Lifealyfics” team.

These are the paper prototypes that they made:

(Lifealyfics / Discover What Makes You Happy / (Begin)

Here’s How It Works / 1. We’ll send you random texts throughout the day, at the frequency you select. / 2. You input your [illegible] and activity / (Then What?)

3. At the end of the week, we’ll send you your results, and you’ll realize what makes you happy and fulfilled! / (Start)

Step 1 of 3 / Enter phone number [text field] / (Next)

The more texts you respond to, the more accurate your personal graph will be! / How many texts per day do you want to receive? [dropdown]

Step 2 of 3 / How many times per day do you want to get a text?

Step 2 of 3 / How many times per day do you want to get a text? / (Next)

Step 3 of 3 / Earliest text: [dropdown] / Latest text: [dropdown] / (Next) )

Here’s some tips for making effective paper prototypes:

First, store all your materials in one place.

You’re going to want to get a bucket of markers, maybe some Post-It notes or index cards.

If you’ve got a mobile device that you’re simulating, you might even make a mockup of something like that,

and you can slide in and out different interface widgets.

Just like the storyboards, it’s important to work quickly.

And if you had a widget that you’re going to use a lot of —

like radio buttons or sliders or something like that —

sometimes it can be faster to photocopy them on a photocopier,

so you can make one version and then photocopy it to have a whole bunch.

Sometimes, good paper prototyping is kind of like playing make-believe as a kid.

So, if you’ve got something that’s complicated or highly interactive,

you can just imagine what it would be like,

and so you can role-play that out with the person who’s trying out your application.

It can be helpful to have a frame to put your interface widgets in.

Here we have a mobile frame.

You can also stick things right on the device itself,

So, if you want to make a mobile screen shot here,…

Mobile user interface!

Or, if you have a desktop user interface, you can take, like, a 11-by-14 sheet of poster board

and put all of your elements on that.

Good paper prototyping is also like collage — you can mix and match fidelities.

So you can use printouts of actual screen shots; draw and annotate on top of that —

anything that you want that can get your point quickly.

And to help the person who’s trying out the prototype

make the conceptual leap between the sketch on paper and an interactive system,

you can add in a little widgets and chrome of your user interface

to convey that it’s part of a larger operating system.

Paper prototyping is not only fast and efficient;

it’s also really fun, and you can get really creative in figuring out different ways to convey interactions.

If you’ve got layers in your user interface, you can use transparencies as a way of showing them.

If you have popup menus, you can make the back sticky,

so that can stay on the right place on top of the main interface.

You [can] use any kind of marker or pen you want;

you can have things be coloured, [or] just black-and-white — Anything you can think of.

You can use poster board (like this), or cardboard, index cards, foamcore —

anything you want as a backing material.

Things like tape are handy to have around.

If you’d like to be able to have repeatable user input, you can use whiteboard markers or transparency pens,

and have a whiteboard or a sheet or transparency that the user input goes on,

and then you can take it away when you’re done.

To be able to add structure to your user interface, you can have line widths of different thicknesses.

So, you can have a thicker line that’s for the major elements, and a thinner line for the minor elements.

And you can have a stack or either Post-It notes or index cards to show the tab panes of your user interface.

So, the different layers can be on sheets beneath.

Here you can see a wonderful widget from the “Lifealyfics” team,

where they’ve created a sliding window inside a mobile phone mockup

as a way of conveying how something would change over time and in response to user input.

The other thing that I’m going to show here, and I’ll touch on several times in this course,

is the importance of trying out multiple different alternative prototypes

as a way of getting more valuable feedback from the user.

So, here are different ways that you could present the data that a live logging system is gathering.

Another reason I really like paper prototyping is that <i>everybody</i> can be involved.

So, if you try out designs with users, give them a pen and have them modify the interface!

Or if they’ve got stuck or think something is weird,

grab a sheet of paper and make any modifications that you need.

You can bring paper prototyping tools into the boardroom, you can bring to clients —

any of the stakeholders that are involved in user interface design,

you can get them involved in paper prototyping.

That helps them get their ideas into the system

and empowers them to play a more active role in the design process.

Once you’re ready to move on from paper prototyping, a useful next step can be to make a digital mockup.

Here’s an example of some mockups

that my research team made for a collaboration with anesthesiologists in the medical school at Stanford.

The first thing I’d like to point out about this

is that you can see that a lot more time went into this digital mockup

than into the paper prototypes that we’ve been talking about so far.

And that’s one of the reasons why I think paper prototyping is so important.

But there does come a time where you’ll want to get more specific about pixels,

and that’s when digital mockups can play an important role.

As your prototypes increase in fidelity — from storyboards, to paper prototypes, to digital mockups —

the kinds of evaluation and feedback that you’re going to get from people are going to evolve also.

So, early on, you might be talking about scenarios with people.

And then, with the paper prototype,

you might be running these informal “Try these out, here’s three alternatives” tests.

These prototypes can also be useful for critiques within your design team.

And as you get to higher and higher fidelity mockups,

you can have the opportunity to get to more formal experimentation techniques.

Rapid prototyping techniques are probably the most valuable weapon you’ll have

in a human-centred design process.

And if you’re interested in learning more, here are some resources that I recommend.

I’ll see you next time.