Practical Paper Prototyping

These are my unedited conference notes. Soon I'll post a better article, with video from the conference.

---

We fail at the wrong time

Here's the problem: we fail at the wrong time.

We fail at the wrong time

invent design build test deploy fail

This is what happened to the Tacoma Narrows Bridge.

All of us fail; all of us are wrong and make mistakes. Far from being something to shy away from, we should rush to and embrace mistakes, for it is only by making mistakes that we truly learn.

Worst place to fail?

fail invent design build test deploy

You could argue that this is the worst place to fail, before we even try.

But then what is the best place to fail?

Best place to fail?

invent design fail build test deploy

Here, I think; this is the sweet spot. We have the rush of invention and the pleasure of design, but have not yet incurred the cost of construction.

If we always fail here, if we always catch our mistakes here, we will always fail as cheaply and usefully as possible.

So that's what this talk is about: how to fail in the right place, consistently.

"Like me"

Frank Herbert once said that the only useful definion of "human" is "like me." This talk is for people like me.

The first software I wrote that was used by another person was a small UI enhancement for my father, on a Tandy 1000. Like everything I've done since then, I care less about how to build the guts than about how to make them accessible.

I've been with OpenSourcery for four years, initially as Lead UI Designer and now as Director of Engineering. I'm part process geek and part union representative for our developers.

Today, my work varies. I've been on one project for over 5 years, and regularly on some new projects I spend only a handful of hours. Regardless of size, these projects have common problems.

Challenge: enough time

For me it's always hard to get what I feel is enough time for quality user-facing design.

Challenge: solving the user's real problem

It's very easy to solve the wrong problem; there are so many. If you hear the user's story only once, and filter it through your own perceptions, as we all do, and there's no telling where we can end up.

Challenge: embrace being wrong

I hate being wrong. Hate it hate it hate it. I hate failing.

But this is one type of work where we must embrace failure, for the faster and more often we fail the closer to the truth we get. Assuming we have a good process.

So how do we fail at the right time? How do we do it quickly, cheaply, and in a way guaranteed to reflect our audience's real needs?

Prototype, Paper, Practical

We create the illusion before the reality, and we test the illusion, and it's surprisingly effective.

We prototype on paper because it's very, very fast. I can sketch an interesting widget in a minute. Humans are fundamentally pattern recognition devices, and we only need enough fidelity to trigger that pattern recognition, and allow people to fool themselves.

By which I mean, you can do it yourself, practically for free, using nothing more than what you have on hand, and what we're going to discuss in the next 40 minutes.

What is Paper Prototyping?

"Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person 'playing computer,' who doesn't explain how the interface is intended to work."

Carol Snyder, "Paper Prototyping"

Let's unpack this. The ideal paper prototyping session has several components.

The user

First, the user. The user you choose should bear some fair resemblance to the target demographic of your application.

The computer

The computer is a person manipulating the created prototypes as indicated by the user's interaction. This person should be as robotic as possible, not responding to anything the user says or does that isn't directed at the prototype.

The observers

The observers are often your team members, other people who are creating the software with you.

The facilitator

The facilitator's job is to keep the computer safe. Users often get frustrated interacting with a prototype, and as the facilitator you can prevent an angry user from throttling your poor computer.

I still keep a paper prototype I made 4 years ago; it's half a page, and it's pretty mangled. It looks almost as if someone grabbed it in her fist and shook it in my face and said, loudly, "I can't work like this! This will ruin my life!"

Don't underestimate how frustrated users can get. Regardless of what you say, they will feel tested.

The facilitator's job really is to focus on the user to avoid frustration. Also to provide instructions, answer questions if appropriate, and push the user a little to discover why they're having trouble.

And they will have trouble because, as we've discussed, it's our job to fail.

The video crew

Video-taping a session can be very useful. One good setup is to have two cameras, one pointed at the user's face and one at the prototypes being manipulated by the computer.

If you search YouTube, you'll find good examples of this.

That's a lot of infrastructure

I'm convinved that many people don't start paper prototyping because they don't think they can get this infrastructure together. And you know what? You don't need it.

Sure, it's useful; I don't have a bad thing to say about any of it. But you can still get excellent results without it.

Let's strip this down to its essence.

Don't be completionist

• Paper
• Pen
• Scissors (optional)

There's not much you really need: paper, pen, scissors.

The essence?

• Simple
• Interactive
• Fast

There's nothing here that can't be done pretty well by one person, that is, you. You can be observer, computer, video crew, and facilitator at the same time.

Not for every context

Now, you're not likely to be able to prototype an entire online banking application this way. After an hour of playing these three roles you'll be tripping over your notes, begging for a video camera.

But online banking isn't the problem we're trying to solve.

What is the problem?

To give us a little taste of how this works, and to try to establish some general axioms, we're going to walk through prototyping and testing a little application.

Now, if I'm going to spend 45 minutes up here talking about something, it had better be funny. And for my money there's nothing funnier than a duck.

A duck

And here's my second favorite duck joke:

Q: Why do ducks have little flat feet?
A: To put out forest fires.

Q: And why to elephants have big flat feet?
A: To put out flaming ducks.

We're going to be building an application for Duck Delivery.

Duck Delivery

We paradrop firefighting ducks anywhere in the Pacific or Mountain time zones.

But can't ducks fly?

Sales call

Sales walks up to me one day and says, "We've got a new client. It sounds crazy, but he rents out ducks and elephants, something to do with fighting forest fires. He wants to get online before the summer fire season. I told him you were our rock star designer, and that you'd come to the meeting with some good ideas."

And he'll be here in an hour

Now, let me emphasize that none of the sales guys at OpenSourcery have ever done this. Seriously, those guys are pros. I always get at least two hours.

An hour, huh? That's not much time.

Ego

And now's where we start talking about ego. What do you want here? Do you want to look like a rock star this first time, right now, in front of this client? Or do you want to solve his problem in the best way possible?

Because if you want to solve his problem you have to let go and stop being afraid of being wrong. Embrace being wrong.

Prototype #1

So we take what our sales guy told us and start sketching. Our goal here is to spend 30 minutes on something quick to show one of our colleagues. I don't know about you, but I haven't designed a shopping cart for a while, and I know that Alex next door has done a lot of ecommerce work. We don't need full prototypes for him, just the sketch of an idea.

What we're going for is a simple home page and then a shopping cart. This seems like enough to cover it: what we do, how to find out more, how to get some ducks.