Comments on PDF Prototypes: Mistakenly Disregarded and Underutilized

John Ferrara — Sat, 11 Aug 2007 13:59:43 GMT

Great article Kyle, thanks for writing this up.

I think that the greatest advantages you’ve pointed out are the ability to go directly from your wireframing application of choice to PDF prototype without intervening development, and then to use those prototypes in remote testing. What’s great about both is that they’re significant efficiency gains, allowing the same amount of production in less time and with fewer resources.

I have one question—when you translate the wireframes into PDF’s, do you usually make all of the links and navigation on the page active, or select narrower functional paths? Does your practice vary from case to case?

Vince Frantz — Fri, 10 Aug 2007 20:12:43 GMT

I started taking my PDFs from Ai into Acrobat to add hyperlinked navigation sometime around 2002. The first reason was to link from Site Maps to related Wireframe pages and back again. This was pretty handy for connecting Site Map or Workflow locations with the relative Wireframes.

Then later that year I got into InDesign and started doing full blown PDF prototypes since I would no longer need to take a pass through Acrobat. So now I generally use only InDesign for all wireframes and some site mapping (mostly OmniGraffle for that now). I don’t always need to make them interactive. But I agree that for a person in an IA/ID role that PDF prototypes are the best of all worlds: Superb print output, Superb on-screen output and great interactivity prototyping – no coding knowledge needed whatsoever.

And with the new CS3 allowing InDesign files to be placed inside other indd files it will be “hello wireframelib!” (haven’t upgraded yet)

Dave Rogers — Thu, 09 Aug 2007 21:16:00 GMT

Great article, Kyle. Thanks for keeping PDF prototyping in the limelight.

I’ve been using PDF prototypes since 2000, primarily for early iteration user testing. Once the basic techniques are mastered, I believe it’s the fastest low-fi prototype method available for non-coders like me. Therein lies its power. If you can use another method more easily, I’m in your corner. Just keep on prototyping!

Not to engage in shameless self-promotion (but I will anyway), those interested in an in-depth look at prototyping with Acrobat can explore my chapter in “Effective Prototyping for Software Makers” (Arnowitz, Arent, Berger. Morgan Kaufmann, 2007, pp.518-569).

Patrick Stapleton — Thu, 09 Aug 2007 11:11:24 GMT

More recently I have regarded Acrobat a bit like a virus. It is so bloated, and forever asking for this update and that – i’ve given up and moved over to Foxit PDF reader. However I noticed a lot of the tricks in your PDF’s don’t function in this reader :(

laurent goffin — Wed, 08 Aug 2007 23:53:36 GMT

I’m a big fan of PDF for wireframes and prototypes since years. Vectorial support and zoom really allow to show long pages with high level of details.

About interactiviy in PDF, you can also use SVG capabilities and Javascript actions available in Adobe Illustrator.

Paul Blake — Wed, 08 Aug 2007 22:50:56 GMT

Very interesting article Kyle, as is Maureen’s view on using Powerpoint.

I’ve just finished work on a project where I whipped up a basic html version with a sprinkling of css very early in the process. This had a number of advantages for us:

1. The client was having difficulty visualising our IA diagrams – the html version put into context for them (and helped us convince them that some of that flabby text just had to go)
2. We had a low-fi version for user testing, which was easily updated as we tested
3. We could do our thing separate to the Photoshop visuals
4. It acted as a de facto functional spec for the developers and when matched up with the visuals gave them everything they needed to build

The key thing is that it worked for us – it isn’t a universal solution. I’m far better with html/css than I am with, for instance, Powerpoint, and it fell into place with this client and this development team.

If other teams, or clients or whoever prefer PDF, Powerpoint, Visio, Photoshop, or whatever and the resource is there to put them together then great. In my view the bottom line is, as long as it’s being tested in a meaningful way then go for whatever method suits.

Kyle Soucy — Wed, 08 Aug 2007 20:59:52 GMT

Henrik,

It sounds like coded prototypes are the way to go in your environment since you can get them done quicker and cheaper. In my experience, I’ve found that is not typically the case. Like I mentioned in my previous post, it’s all about what you are comfortable with and proficient using. There is no perfect prototyping tool or method that fits everyone’s needs perfectly. Depending on your skills, environment, or needs of the project, different tools may be more effective at achieving the level of fidelity you need in a prototype.

Kyle Soucy — Wed, 08 Aug 2007 12:56:14 GMT

Hi Fred,

I’m happy you liked the article and the examples. Unfortunately, you can’t create layers in Acrobat. The layers that appear in the PDF document are based on the layers created in the original application (Visio, InDesign, or AutoCAD); however, Acrobat does give you the ability to show or hide each layer in response to a user’s actions.

I’ve heard nothing but great things about Axure. I’ve only briefly played around with it, but I plan on really getting my hands dirty with it soon!

Henrik Arndt — Wed, 08 Aug 2007 11:42:26 GMT

Thanks Kyle and Terry for considering my comment.
Maybe I wasn’t clear enough, so I’ll elaborate: If a programmer codes a part of a website or a webservice as a prototype it does not mean that it looks (or is) finalised (especially if a CMS is used). There is to all intent and purposes no difference between the appearance of the coded prototypes that are used in my projects and the wireframes that are shown in this article. The problems that can appear if a seemingly finalised layout is tested or presented too early in a project have nothing to do with the decision to code a prototype. But none-the-less, coded prototypes are faster and cheaper to build and in many cases the code can be used in the final production.

Fred Beecher — Sat, 18 Aug 2007 09:42:37 GMT

Enlightening article, Kyle! I’m glad to see so much press being devoted to prototyping lately. I’m a huge fan of that particular practice (Axure being my weapon of choice).

And I have to admit that I suffer from many of the misperceptions about PDF prototyping that you mention. :) Most of my experience doing PDF prototyping has been trying to use Visio’s byzantine layering system to get the interactivity going, and then hoping Acrobat picks it all up. For me, it’s much faster to use Axure. At my company, I recommend that we use Axure for any project that either a) is highly dynamic or b) will require remote testing.

But what you’re saying is that we can do all that in Acrobat… I should take a closer look, as previously I have regarded Acrobat as a necessary (and insanely bloated) evil. One thing I’m *not* clear on though is how to do dynamic layering within Acrobat itself. Would I need to import images of the layer or something like that? Please don’t make me create a Visio layer. Just… please. : )

(Also, your hand-drawn interactive prototypes are fabulous!)

Laura Veprek — Tue, 07 Aug 2007 16:30:15 GMT

Kyle,
I think this is a great article. It shows the potential power of using PDF for prototypes. Thank you for posting it!

As the others have said, boils down to personal preference and organizational preference whether and how these PDFs are used. For me, as a designer/developer, I am the one who creates the mockups and then gets to code it. I would much rather create a Photoshop mockup, then send it out as a PDF for people to comment on before I spend time coding. It’s much, much easier to work out major changes, like layout, in Photoshop, especially if you have more than one design to choose from, than to code, and re-code, and re-code…That would likely just produce messy code. Not to mention that if you use a coded mockup, you’re still faced with many unusable parts. So why not make a prettier picture? As a last point, if you’re doing the prototype for a proposal, and not necessarily a guaranteed project, I would say you get more bang for your buck with a PDF than with a live, coded site.

Weston Thompson — Tue, 07 Aug 2007 16:10:27 GMT

I like this idea for using PDFs as prototypes, and I intend to add it to my toolkit. There are times when you need a more advanced prototype and want to work with your coders/developers for that. There are times when paper is the way to go. There are times when doing your own ugly HTML is the way to go. I like being able to scoot up and down the spectrum depending on my time, the project’s constraints, and what we need to learn at the time. Thank you Kyle, for this nice how-to article.

Terry Bleizeffer — Wed, 08 Aug 2007 20:58:59 GMT

Henrik: There are many times when I work with a developer who codes the prototypes. In my experience, we use that technique when a) the UX team is in “consult” mode by commenting on the design that the developer is creating, b) we’re too late in the cycle to do usability testing, or c) the amount of design is so small that we don’t care enough to spend time doing the prototyping ourselves. Those are reasonable, common situations, but it’s not the model we’re shooting for.

I also create prototypes by writing code myself, especially if the end code will just be HTML and JavaScript. If I expect a lot of iterations in the design and/or I expect that there is so part of the design that requires “real” interactivity for useful testing, the investment of time necessary for coding it myself can save time and effort in the long run. For me, these are often the most enjoyable design projects, but there are plenty of cases where it’s just overkill.

Using PowerPoint (or PDFs, though I haven’t tried that before) to do quick prototypes is a great tool in the toolbox for situations when you have limited time, need a lot of eyeballs on the design, only require some simple interactivity, and don’t expect endless iterations. In my job, expecting a developer to create my prototypes is wildly unrealistic.

Kyle Soucy — Sat, 18 Aug 2007 09:37:19 GMT

Henrik, you asked a great question, why should you use Acrobat or other tools to do low-fidelity prototyping if you have a developer available to code? Here are a few reasons:

1) You’re able to get feedback early in the development process—before you’ve invested more time and money into the development effort. You may have access to a developer that can code anything quickly, but is it worth their time to code a design before you even know if it’s usable?

Everyone has their favorite prototyping tool, just like everyone has their favorite wireframing tool and I think it’s a personal choice and depends on what you’re comfortable and proficient using. I know people who can code a CSS prototype much faster than they can whip up a Powerpoint, PDF, or Flash prototype.

2) A team tends to get married to their design once it’s been coded. Again, this depends on the environment you work in, but it’s common that developers and other team members are reluctant to make changes to a design once they’ve spent time coding it. Also, in my experience, once a higher-up sees it “live” they start wanting it done yesterday.

3) Users tend to feel inhibited to give feedback on a design that looks too “polished”. If you’re testing your prototypes (which I hope you are), you’ll find that users are more comfortable being critical of a prototype that doesn’t look finished.

4) Since it doesn’t require technical skills you’re not reliant on your developer. What if that resource was no longer available?

Carolyn Snyder described the benefit of paper prototyping in her book as, “maximum feedback for minimum effort”. I’d say that’s the goal of low-fidelity prototyping. It doesn’t matter what tool you use to prototype as long as you are getting the most out of it without having to put forth a lot of effort.

UIE also has a great article on 5 Prototyping Techniques (http://www.uie.com/articles/prototyping_tips/) that covers the debate of coded prototypes vs. paper prototypes.

I hope this helps to answer your question.

Henrik Arndt — Wed, 12 Sep 2007 19:04:52 GMT

I can open a bottle of beer with my gaspipe pliers. But why should I? If I wanted to open a bottle of beer, I’d use a bottle opener, even if I am able to open a bottle with many other things (and even if that would look much cooler).
Of course I can prototype a website in Powerpoint, as Maureen explains, or in Acrobat, as Kyle demonstrates. But why should I? If I wanted to prototype a website, I’d ask a programmer to adapt my scribbles, wireframes or layouts into code. That does not take much longer than building a prototype in Powerpoint or Acrobat (the larger the prototype, the faster the programmer compared to me prototyping with Powerpoint or Acrobat).
Programming prototypes has so many advantages compared to Powerpoint or Acrobat. Changes can be made much more easily (as only the altered element has to be changed, as opposed to all touched pages). Many things beyond the UI can be tested (e.g. if the navigation can be implemented with the CMS as planned, or if the data from a database can be filtered and presented as intended).
If I only want to have a quick feedback on a few pages I’d show (or test) wireframes (non-interactive). These does not present less information to testees or clients than those “You-only-can-click-here” or “This-page-is-not-available-in-this-prototype-please-go-back-to-previous-page” prototypes.
Let the programmer prototype and in the meantime work on your next project.