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.

OpenSourcery is proud to announce this week's launch of the new STAR Autism Support website. As with every OpenSourcery Drupal site, STAR Autism Support is about functionality and intelligent user interface -- we believe websites should be tools rather than mere pretty faces.

Among the features that give STAR Autism Support long-term value:

• eCommerce: visitors can purchase educational materials using ubercart
• Event registration
• Easy-to-use calendar for events and seminars
• Event and site update feeds
• And soon STAR will increase the site's functionality to display video previews

Developer Dylan Tack wrote a custom module to drive the menu, such that images can be associated with menu items in an attractive, consistent manner. Look for a release of this module on Drupal.org in the near future.

We hope you'll visit their site and learn more about the incredible people and projects behind STAR Autism Support.

We're excited to roll out refactors of two sites OpenSourcery had the pleasure of working on in the past. Our clients had very different reasons for reexamining their content and design, but we think both resulted in tangible improvements.

The first redesign, for Fuel, took place because the film has been picked up for broader release. We're very excited for the team over there, and we wish them the best. Check out the website to learn more about times and locations. They've changed the title, revamped the site, added more multimedia, and generally created a more robust user experience.

The second redesign we've rolled out this week comes from Wellgram, which allows users to create email or text message reminders that help them achieve goals, improve self-control, remember important tasks, etc. Most importantly, you can schedule receipt of reminders to keep you on track. Write your own Wellgram here. Our work with Wellgram is another example of an Agile project gone right.

We urge you to check out both sites take advantage of the tools they've made available.

Thank you for reading.

The Linux Foundation, which provides value to thousands of users every day, has decided to highlight the community's creative spirit by hosting a video contest. Of course, they needed the right tools to get the job done, so they asked OpenSourcery to design and develop a website for their user-generated videos and their internally produced videos.

We encourage you to visit their current video gallery, which is home to dozens of keynote addresses, panel discussions, and informative interviews. It's a wealth of information that already generates a lot of interest. We're very excited to redesign the site so it's easier for visitors to intelligently search for the content they need, explore related videos, and even give back to the community. It's the kind of work our user interface and informtion architecture lead, Randall Hansen, loves to take on.

OpenSourcery's Drupal developers will update the Video Upload module we created for Drupal 5, and make it available in Drupal 6. It's one of Jonathan Hedstrom's contributions, which you can learn more about here or read about in his blog. Since our team is full of Linux devotees, this project is like a dream come true. Keep your eyes out of the new site, which should be up and running before the holidays.

Last week I talked about the driving forces behind the redesign and redevelopment of OpenSourcery's public site. Those forces boil down to: upgrading from Drupal 5 to Drupal 6, improving the information architecture, and making it easier to administer content on the site without breaking the look and feel.

But today I want to cover the challenges of parsing site re-design into a three-part cycle: content creation, shaping content into a coherent design, and development. Repeat.

Content, design, development. We're discovering that this cycle is the most efficient way for us to move forward. As with any internal project, we could easily pull a hundred ideas out of the sky and try to implement them willy-nilly, but the time and resource constraints force us to be intelligently iterative. In other words, every minute of time devoted to the project needs to address the most pressing needs, and it needs to create immediate value. Sounds easy enough, right?

To me, creating copy in advance of design seemed like writing the lyrics to a song and passing them along to the composer so he or she could construct a melody around the words. At first I found it extremely difficult. I couldn't envision my words floating in the ether; I had to think of how they would look on the page, how they would be framed, etc. I wanted so badly to know the design before I wrote the copy so that I could simply drop my text into a beautiful box and call it a day.

But the mere act of releasing myself from the shackles of envisioning everything at once has provided relief. It refocuses the act of writing on the rhetorical aspects: what is the audience, what message are you trying to convey, how can you increase efficiency?

The three-part development cycle we've devised stands on its merits. My analysis is that both efficiency and focus increase as a result of parsing the huge task of internal site creation into manageable parts, and then handing those parts to the individuals best suited to deliver value.

Next week I'll share observations from the perspective of a marketing director acting as client in the office at which he is employed. I promise fireworks.

Thank you for reading.