Why low-fidelity prototyping kicks butt for customer-driven design

Low-fidelity prototyping versus high-fidelity prototyping
In my discussions with designers, one of the interesting recurring conversations is the tools and process they use to prototype and mock up experiences. In particular, there’s a lot of divergence on how high or low-fidelity to go with a prototype.

For designers that primarily come from agency backgrounds, I’ve found that there’s an emphasis on quickly getting to a near pixel-perfect mockup, and the variations are minor in detail. In that worldview, the ideal deliverable is a single version of something that feels high-quality and gets minor feedback from clients. In the client-agency model, if you give your clients a bunch of rough mockups that seem low-fidelity, then you risk looking unprofessional. Or worse yet, you might get a ton of diverging comments that you then have to work out and iterate – in some cases that’s the last thing you want to do.

This is especially not a good situation for companies that focus on products delivered to customers – in that case, you mostly want your product to be the right one, no matter how many iterations it takes. As a result, low-fidelity prototyping can be really useful because it aids an iterative, customer-focused approach rather than one where the Great Designer comes up with something directly from his brain.

Here’s a couple of the main advantages:

Get better and more honest feedback
It’s great for A/B testing
Make the cost of mistakes cheap, not expensive
Refine the page flow, not the pages
Figure out the interaction design rather than the visual design

In addition, after I’m done arguing my point, I’ll recommend some of the tools that have been useful for me in doing low-fidelity prototyping.

Get better and more honest feedback
The first time I really undestood the power of low-fidelity prototyping was when I started doing usability tests on consumer products I had built (This was years ago). Initially, I wondered why anyone did paper-prototyping? I immediately concluded that it was due to a deficiency of many designers that they couldn’t write code, and thus couldn’t do HTML mockups of the products they wanted to build.

But once I started getting people to view and interact with my prototypes, I realized that one of the big problems was that people didn’t give good feedback when the prototype you present to them is too perfect. Rather than telling me about the really high-level things, like “does the value proposition make sense?” instead they would focus on colors, fonts, the layout of the page, etc. And furthermore, they didn’t feel that they could really jump in and build on top of the ideas you showed them, because it was far beyond their capability to duplicate.

Compare this to a simple exercise where you are using hand-drawn cards or drawing paper and are literally sketching stuff out during a customer interview – you’re much more likely to try something out, and have the person you’re interviewing grab your pencil and say “no, more like this!” And that’s exactly the kind of interaction you want.

It’s great for A/B testing
As for as a metrics-driven approach goes, you have to remember that techniques like A/B testing fundamentally thrive off of variety. In particular, it thrives off of variety at the UI layer, where many small UI changes that cost very little technically can be tried out and optimized. As a result, you don’t want 2-3 pixel-perfect mockups, you actually want 10 or 20 rough mockups where you can select only the most high-variance candidates.

Some of the highest variance stuff has to do with changing the order in which you do things, or opt-in versus opt-out, or richer AJAXy interactions. These are all things where it’s easier to generate many candidates through low-fidelity prototypes since you’re often looking at things form a systems level.

Make the cost of mistakes cheap, not expensive
One of the hidden benefits of having a low-fidelity prtotyping process is that it makes changing directions much easier, which naturally facilitates a collaborative design discussion. When you’re using a customer-driven product philosophy that incorporates a lot of outside metrics and qualitative feedback, you’ll probably get multiple people involved in the design process. If it’s done by one person or a small group, and is polished significantly before it reaches the greater group, one of the problems is that it discourages collaboration. It’s very hard for people not to get defensive when they’ve spent a lot of time polishing something only for it to get changed significantly. Using a low-cost process makes it so that you can try a lot of variations cheaply, without any of the emotions involved.

Refine the page flow, not the pages
One of the highest leverage design decisions you can make is not about the look of an individual page, but what happens before and after it. For example, you can take a multi-step process and condense it onto one page, or change the ordering of something so that you do something and then register, rather than the other way around. These kinds of design decisions ultimately focus on the order and flow of the user, rather than the look or interactions of any specific page. If you go with a low-fidelity, then it’s easy to draw lots of small pages and link them up in a flow, and do things like cross pages off, change the ordering of a funnel, and lots of things that feel natural when the prototype is very rough. Otherwise, it’s too easy to get caught in the details on the “right” way something works without exploring the options.

Work your way up from low-fidelity to high-fidelity
Of course, you want to make sure that you use the right process for the right job. So there’s nothing wrong with high-fidelity prototyping, especially when you are in the later stages and thinking about issues like branding, look and feel, and all those other details. One way to keep this process going is to have multiple rough prototyping checkpoints so that design decisions are constantly getting refined – maybe the first step is a sketch on a paper, the next is a rough mockup on the computer, then a detailed mockup, then a rough built-out version, and then iterate to the final product. These steps make it so that all the design decisions are well understood, refined, and debated all the way through.

Tools I recommend
Finally, a couple recommendations on tools for paper prototyping:

Number 2 Pencil :-)
Giant art pad for drawings – you can get these at an art shop or office store
Balsamiq (check out the video on the linked page)
Macromedia Fireworks

In general, nothing beats pencil and paper, but that’s just me ;-) I’ve been told that for people who aren’t comfortable drawing, using tools like Balsamiq helps quite a bit.

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

Like this post?
Get new updates via newsletter..

http://twitter.com/dbenyamin dbenyamin

Andrew, have you looked at Axure? (http://www.axure.com) Its emphasis is on easy-to-capture interaction, and has been especially helpful for us to test flow & navigation. And its output is html that can easily be sent off to folks for review and test. While I agree paper is best to start, there seems to be a void between paper and full blown drawing tools.
http://andrewchen.typepad.com Andrew Chen

I just checked it out, and the mockups look too perfect ;-) Do they have something rougher / more hand-drawn?
Name

you could always try http://www.balsamiq.com/products/mockups – it's a lot of fun to use and the client participation/feedback we have obtained using it has been great
http://twitter.com/dbenyamin dbenyamin

How important do you think that is? Meaning, black and white pages with helvetica and plain boxes I don't think necessarily convey “finished product” (at least I haven't seen that as a misconception).

Besides, you could always just use a cartoon font ;)
http://twitter.com/DavGarcia David Thomas Garcia

Microsoft Expression Studio 3 has SketchFlow, a rough-looking prototype software. But I'll stick to my #2 pencil, thank you. http://www.microsoft.com/expression/products/Sk…
robfulop

Great post. I've designed video games/interactive entertainment for many years and have had this particular discussion more times than I can count .. there are several points in a project's life when it makes sense to put what we have in our heads in front of other people. The question that always comes up is “how 'good' is 'good enough'” for our concept pitch or the prototype demo or the alpha test.

To me it all depends on the audience. If I'm showing something to a person experienced in looking at early stage work .. then I'm all for showing rough pencils, etc. When showing something to internal management, ESPECIALLY those with MBA's … we' typically purposely make something look as “sketch-like” as possible. Often such resembles a blueprint with blue background and white lines … precisely to send the unspoken message that this is nowhere near “finished” so please don't comment on our choice of font, or colors, or whatever design choices the particular executive feels is “right”. What works well in this case is to actually ask the person looking at the work to help choose a font, or color palatte … they now only feel involved this way … as well as focus on what you want them to focus on.

But when showing something to an END USER … I pretty much insist on a “pixel perfect” fake of the real thing because I can't afford a 'false negative' which can happen if you show unfinished stuff to somebody who doesn't typically look at unfinished work. When they give a thumbs down to a dirty/rough presentation, we as designers can always use the excuse that the 'trial' doesn't really count … and talk ourselves into continuing what may be a bad idea. I'd much rather go into a presentation to an end user KNOWING that their “NO” really means “NO” … and I don't leave myself the excuse of “well, they don't know how to evaluate unfinished work”, etc. If I'm going to say such a thing … why bother running the thing by the end user in the first place?

So presenting to in-house management = rough/dirty stuff is fine and often preferred so they focus on the real goods under consideration

Presenting to end users = would never dream of showing something that looks unfinished because we can't risk dismissing a thumbs down as a 'false negative'.
lauraklein

I think that you're setting up a false choice here. While it's certainly true that when something looks too perfect, people can be hesitant to give feedback or recommend changes, there is a very important option that lies between rough, hand-drawn sketches and pixel-perfect designs. I routinely (and quickly!) create interactive, gray-scale wireframes that allow people to perform tasks but don't dazzle them with flashy graphics or pretty visual designs. I've been creating these and testing them for years, and I've found that they are absolutely the best way to get feedback on the usability of a product.

It's really hard to test or discuss actual interactions with paper prototypes or sketches. In a user test, a hand drawn sketch is only testing screen layout, not whether users can figure out how to perform complicated actions that might involve things like navigating between multiple screens, filing in forms, manipulating data, or any sort of transition between states. An interactive prototype, not a hand drawn sketch, is the most effective way for figuring out whether people can actually use your product.

While I agree that it's a good idea to move from low fidelity to high fidelity in prototypes, I strongly recommend that you introduce interactivity well before the “later stages” when you're thinking about branding and look and feel. Make your prototypes interactive when you're thinking about things like, “can users actually perform the tasks that they need to perform when using my product?” If you're interested in answering that question as early as possible, it's really important that you not skip directly from hand drawn sketches to pixel perfect mockups.
Kathy Sierra

Oh wow– so many of us have learned the hard way that for both useful/broad feedback and to keep expectations realistic, the “doneness” of the demo should match the “doneness” of the product.

The Java Napkin Look And Feel toolkit was made for just that purpose:
http://napkinlaf.sourceforge.net/
Leticia

I'd use “low-resolution” instead of “low-fidelity”. Even if one of the meanings of fidelity is “adherence to details”, the most common use refers to “accuracy”. Thus, a low-fidelity prototype might convey the idea of inaccuracy, which is not at all the essence of low-res prototyping.
http://www.betterlabs.net Vaibhav Domkundwar

I agree but I like to use Mircosoft Excel as it allows me to make the mockups very detailed and granular so it almost feels like HTML. Most people I work with and show the XLS UIs think I am crazy but love the UIs anyway :) I would have loved to paste a screen capture of that in the comments but can't do that!

Great post!
http://andrewchen.typepad.com Andrew Chen

Wow I have never heard of an Excel-based prototype. Care to share one? I would really enjoy seeing it.
http://andrewchen.typepad.com Andrew Chen

Laura,
I agree that of course, you should increase the fidelity as you go up. But early on, imho, the most important thing to get feedback on is the core concept, some of the high-level interactions and flows, in what order things happen, etc. At the point where you are testing interactions on one page, then you have to get down to a much more granular level. This is especially true if you are doing things that may be strongly affected by “polish” elements like button color, headlines, help text, etc.
http://andrewchen.typepad.com Andrew Chen

Thanks for sharing! Very interesting to dissect presenting to end customers versus execs, and how you might want to change things. Absolutely they have very different motivations.

The same might be said for investors versus press/analysts versus team members. All very different degrees of what you want to emphasize.
http://andrewchen.typepad.com Andrew Chen

Ha! I hadn't seen the Napkin Look and Feel toolkit. The same should be made for Adobe Flex and Javascript/jQuery, since those are often incorporated into web prototyping these days.
http://blog.slicedbreaddesign.com Laura Klein

You know, I think part of my bias is that I'm very fast at creating basic HTML/JavaScript wireframes, so I tend to start with interactive wireframes early on, long before we get to things like visual design elements. I find I get better feedback on the core concepts with interactive wireframes even in the fairly early stages, and honestly, they're easier for me to update and iterate on. For example, I don't have to resketch the whole thing from scratch every time I want to move an element or change some navigation. I just swap out some CSS, and I have a brand new version.

I've also found that most of my recent projects have had a lot of functionality on each screen. I've had to start thinking almost immediately about what the interactions within each screen were going to be in order to help me figure out the flows for common use cases.

I do agree with you that there is a time and place for sketches and that the fidelity should increase as you go. I have just seen so many people skip right past designing and testing the interactive parts of their applications that it makes me nervous when I hear people talk about how wonderful paper prototypes are!
http://www.comradity.com K. Warman Kern

Big fat pencils and plain white paper were also the tools at Leo Burnett, back in the day.

Conference rooms – used mostly to get away from the phone and brainstorm uninterrupted – always had a pad of blank white paper and a big fat black pencil at each seat. Because Leo, I'm told, believed that no lines on the paper and a big fat fuzzy pencil line forced you to say what you are trying to say as simply as possible – whether in words or visuals.

Also, from my experience. People get very literal when they don't know what to say or how to react to something. So if you give them executional detail before they've bought into the overall concept, they will get distracted. (Maybe to avoid telling you they don't get or like the overall concept?)
Andrew R.

Laura, in taking your approach of building basic HTML/JS wireframes, do you find that you can easily add the final visual elements to those wireframes, or do you only use the wireframes to test interaction and pageflow but then start again when slicing/coding the final design?
http://www.flairbuilder.com/ Cristian Pascu

Hey,

FlairBuilder will very soon feature a Napkin like l'n'f letting you create complete interactive prototypes that look hand-drawn. It's a very exciting combination and I'm sure people will love it. :-)
http://andrewchen.typepad.com Andrew Chen

Hi Cristian,
is Flairbuilder your project? Would you email me when the new versoin is out, so that I can review it? Thanks.
http://andrewchen.typepad.com Andrew Chen

In reality, the design will probably be both low-resolution, low-fidelity, and very inaccurate ;-)
http://blog.slicedbreaddesign.com Laura Klein

There's a real trade off here. If the goal is to very quickly mock up a bunch of rough wireframes and then do several iterations during testing, the HTML and CSS can get messy pretty quickly. As with anything, the faster you go, the less likely you are to have something production quality at the end. However, if you follow decent semantic markup guidelines, some of it can be reused later.

Also, if I've written a lot of JS for transitions or any other sort of interactivity, quite a bit of that seems to be reusable, since the logic's all there, and it just needs to be tweaked if the HTML changes.

I'm actually going through this process currently with a project, where we specifically took a little extra time with the wireframes in order to save time later during implementation. I think it will end up being quite a bit quicker, but it's a fairly simple project where we're doing the implementation, which isn't generally the case. Larger, more complicated things like full web applications that have big teams of programmers working on them often still need to be built from scratch.
http://www.betterlabs.net Vaibhav Domkundwar

Just sent it to you via email. Let me know what you think :)
bookmousey

I like the division between showing the low-fi prototypes to execs vs end users. But then another comment mentioned that without interactivity, you are not actually measuring the usability of a product.

Another distinction that might be useful here is the purpose of the prototypes.
Possibly when testing usability and interaction, an actual css/js wireframe would be better, whereas if I am still at the concept stage, the paper prototypes will help the iteration process move along quicker.

Currently I am planning on developing some tests (for end users) using paper prototypes, and the main reason for this is to help define the feature list of the project. Personally I have not done user testing with lo-fi prototypes yet, so we'll see if it works.
huang

Frozen winter is coming,do you like to buy ugg to preventing cold and keeping warm.As a pursuer for the most stylish ,is there any ugg boots you have in mind?I think you have no excuse anymore if you don't have a pair of UGG Bailey Button Boots.The Bailey Button UGG can be worn as a UGG classic short Boots or UGG classic mini Boots . Hottest pop style.If you like the UGG tall boots,www.realugg.com can provide high quality of Ugg Tall Boots in low price,Are you straitened for Ugg Boots Insoles,don't worry ,we have the best Ugg Boots Insoles on sale ,many of which are hand made by craftspeople.RealUGG,Inc came up with some new-styles- Ugg Lo Pro Button , Ugg Women's Rainier, We offer a wide range of UGG Boots in different color and styles. Browse the website, we are sure you will find Real UGG to tempt you!
jasonrobb

Outstanding post, thanks for taking the time to write about this. You're emphasis on refining the page flow rather than the page design is priceless. Defining the interactions makes it so much easier to visually design the page.

Well said, I'm really excited about the article. Thanks again!

Cheers,
Jason R.
Erik

Great article – thanks!

I believe that the level of fidelity of your prototypes needs to match the stage of the process you are in – which I think you alluded to in the article. It's important that the process be iterative. If there is a solid iterative approach at the beginning, sketching with the customer/client can go a long way to fleshing out the best ideas early on. This also helps to set the expectations of deliverables at this stage, keeping everyone on the same page. Also, sketching helps to keep any “visual design” issues at bay, and retain focus on the interaction design.

Thanks again,
erik
besocial

Connect-A-Sketch is really cool app that let's you draw out sketches, as Andrew suggests, and then drag and drop them into a prototype:

http://bit.ly/3w40C8
Michelangelo

I am surprised that no one mentioned Axure Rp. It allows your prototype to be as rough or as polished as the stage of the project demands; it maximizes reuse and quick updates across pages through the use of templates; most importantly you can annotate every object or page.

But as always, pencil and paper are a must. (or 'marker and whiteboard' if it is a joint design session). I use them to clarify the flow in my head before I fire up any software.
jack

i was wondering if you anything about php#/
http://blog.slicedbreaddesign.com Laura Klein

Do you mean for prototyping or for building applications?

I've used it for both, and it can be helpful for prototyping, but the vast majority of designers don't know it. It can be a bit of a hassle, since you need to have a server to run it. Also, I haven't really seen any good php tools that help you quickly build prototypes, although there certainly might be some out there.

In general, I'd say it's way too heavy duty just for building interactive wireframes, unless you happen to already be great at using it.
Marcus_Dane

I agree with you. Nothing beats pencil and paper. I do that most of the time before doing a high fidelity web site prototyping. At least, the mistakes would be lessened in the lo-fi before I make it into hi-fi.
Marcus_Dane

I agree with you. Nothing beats pencil and paper. I do that most of the time before doing a high fidelity web site prototyping. At least, the mistakes would be lessened in the lo-fi before I make it into hi-fi.

@andrewchen