The User Advocate: Interactive Prototyping
Part 1: Easy PDF Prototyping

By Dave Rogers

End-users are the ultimate arbiters of a site or application's success. No matter how skillful or gifted the design and development team, neglecting user perspectives puts our projects in great peril.

As you probably have guessed, I'm passionate about bringing end-users into the design and development process. The idealist in me would invite users to join the project team—but my rational self reminds me that this is a fool's errand, laden with pitfalls.

Instead, through extensive analysis, usability testing and personas, I seek to understand user needs and goals in such a way that I can advocate for them.

While there's ample opportunity to do so early in a project, I've often observed that once wireframing begins, it's off to the races! In the rush to launch, we sometimes forget end-users. Is there a way to ensure that they get a voice during this always-hectic phase?

There is. Site prototypes are the answer.

I've been huge on prototyping since I read Michael Schrage's Serious Play: How the World's Best Companies Simulate to Innovate (Harvard Business School Press, 1999). Schrage contends that prototypes create "shared spaces" that facilitate collaboration and innovation. I love this because it means prototypes can transform users into collaborators.

How? Schrage explains that it's much easier for clients to articulate what they want by "serious playing" with prototypes than by listing requirements or sharing in focus groups. Prototypes find their value, he says, not in the models themselves but in the interactions they create. Prototypes by their nature are provocative—stimulating the discussions, debates and decisions that drive innovation and problem resolution.

And we must share prototypes with end-users if we want optimal results. Schrage insists,

To succeed today, the prototype can't be seen as the property of the engineers, designers or marketers—it has to be seen and treated as community property. And the most important member of that community must be the customer. The customer must have an opportunity to play with and relate to prototypes as they evolve.

We all agree that prototypes are valuable. We'd all like to submit iterative designs to user testing, from initial wireframes all the way to launch. Yet this seems rarely done. Prototypes are seen as time-consuming, difficult to create and a diversion of limited resources. As a result, they become optional, squeezed into a project timeline when it's usually too late to make changes.

To counter this, we need prototypes we can create quickly with a minimum of effort. Paper prototypes are the favored solution. In the must-have Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (Morgan Kaufmann 2003), Carolyn Snyder defines paper prototyping as "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."

I love paper prototyping and find it particularly effective in the early stages of development with low-fidelity models. But I'm not here to talk about paper prototypes. Snyder's book (and the Nielsen Norman Group's helpful DVD) gives you everything you need.

For higher fidelity models, I'm more interested in digital prototypes—those that look and "work" much like the finished site or application. Unfortunately, these draw the most fervent objections because of the perceived need to dedicate scarce resources to build the prototype in HTML, VB, Dreamweaver or other tool.

Wouldn't it be great if there were a way to create digital, interactive prototypes as quickly and easily as paper prototypes? One that didn't require a programmer? One that didn't duplicate efforts? One that could handle high-fidelity designs as well as low-fidelity?

I'm here to tell you that there is. For years, I've been successfully using Adobe Acrobat to create working PDF prototypes directly from my wireframes. There's some sleight-of-hand involved, but Acrobat gives me fast, easy prototypes at whatever fidelity I require.

"Now wait a minute," I hear some say. "Acrobat isn't made for this." That's correct; Acrobat is not intended a prototyping tool. Yet its suite of utilities permits everything from simple HTML-ish links to realistic (and working) forms.

"Why not build the prototype in your wireframing tool?" asks another. That's certainly possible, but it mixes apples with oranges. Design is design; building a prototype is something else altogether. It's important to keep your focus on the task at hand.

Further, there are situations where efficient wireframing conflicts with prototype creation. For example, background pages in Visio make wireframing much easier, but any assigned links don't carry over to the foreground. And working forms (dropdowns, text fields, radio buttons) are difficult to create in Visio.

Carolyn Snyder points to three main activities in prototyping. Applying them to PDF prototypes demonstrate the benefits of the Acrobat method.

1. Designing is "thinking about what the user will experience." Snyder explains that while prototyping methods don't necessarily help design they can constrain it. Because Acrobat prototypes are created after the design phase, they have no impact on this critical process.
2. Rendering—in this context, wireframing—is creating what the user will see. The diagramming tool takes care of this. You create, duplicate, modify and polish the wireframes first. Only when they're completed does Acrobat come into play.
3. In all prototypes, coding—adding behavior to the interface—requires the most effort. In her book, Snyder vividly explains how this can grow to monstrous proportions. On the other hand, "coding" PDF prototypes means adding the links and forms that make the wireframes interactive.
   
   In most cases, there's no programming knowledge involved; if you can use a diagramming tool, you can add behavior to a PDF. I won't lie to you—there is effort involved, some of it repetitive and monotonous. Yet I find it no more difficult than creating a paper prototype.

Acrobat is not a perfect prototyping tool—yet it does place easy prototype creation into the hands of UX practitioners. In Part II, we'll take a step-by-step look at creating PDF prototypes and using them in usability testing. I'll also address some of Acrobat's limitations and suggest workarounds.