Interaction Happens: Prototyping Techniques
See if this situation rigs a bell: a manager tells you to build
a proof of concept to test the look and feel of a new
application. You hack for a week straight, day and night, producing
some of the ugliest code you have ever seen to make the Big Demo.
After all of your hacking, the meeting is a huge success and
everyone loves your prototype. Then someone asks you how long until
the application is deployed. You respond with a reasonably worked
estimate of six to nine months. The feeling in the room quickly
changes like someone just stopped the music in a bad 80s show. No
one understands why its going to take nine months to build
something that they already see in front of them. No one is
happy anymore. Uh-oh.
What's really going on in this story is full-fledged,
high-fidelity prototyping (don't worry, I'll explain what the "high
fidelity" means in a bit). This approach to prototyping has some
dangers that were not mitigated and led to potentially dangerous
This article takes a high-level survey of some of the standard
prototyping methods. You'll learn a little about each of the
methods; where they work, and where they don't. Wherever possible,
I'll embellish this with examples of the different prototyping
methods, from my experience and others'.
Why Are You Prototyping?
First, it helps to figure out why you are prototyping
in the first place. You'll be more informed when choosing a
prototyping method the more you know about why you're prototyping.
Here are a few popular reasons as example (your actual reasons will
- Getting "buy-in" from stakeholders.
- Helping business analysts gather requirements.
- Running a usability test before full production.
- Testing an architecture.
- Testing a series of interaction widgets (a new text field, for
- Designing by tinkering with working code.
- Resolving flow issues when all you have are some screenshots of
what your application is supposed to look like.
Keep in mind that this article focuses on interaction design in
prototyping. So although testing an overall system architecture
code is a reasonable thing to do, we'll call that more of a
proof of concept rather than a prototype. With that in
mind, it's also important to consider your working environment.
Here are a few example questions to ask yourself.
- Are you working on an internal project or do you work for a
- Are you in a hostile work environment, or is there a fair
amount of trust?
- Are you working under very strenuous deadlines?
Keep all of this information in your mind as you read the rest
of the article. This is also a good time to decide whether or not
to prototype at all.
To Prototype or Not to Prototype
There is a recurring debate in software development about
whether or not to prototype. This is the same type of religious
argument that wages around which IDE you currently use, type-safe
versus non-type-safe languages, object-oriented versus functional
programming, native versus custom look and feel, and so on.
Proponents of prototyping make the point that prototyping helps
with upfront design, making development easier since everyone knows
what to build up front. In practice, I've found that analysts and
managers tend to like prototyping because it gives them something
tangible--however unreal--to latch on to. This can be a great
help in facilitating requirements-gathering from users. Prototyping
can also help analysts write requirements docs.
Opponents of prototyping are often realists who see too much
prototyping as a time drain, if not a complete waste of time. Full
upfront prototyping with complete specs before development fits the
waterfall development methodologies and is generally out of favor
these days. Things change during development, as preconceived usage
changes and corner cases are discovered, often rendering prototypes
irrelevant, or at least of less useful than previously thought.
Agile development avoids prototyping almost entirely by
iteratively honing in on a UI design with the code. This works well
for internal software development with understanding users. It's
more difficult for product vendors who don't really have the leeway
for iterative releases. Product vendors often have one real shot at
the market with an innovative product. It has to be right, or at
least really good, right out of the gate.
But there is a middle ground. There are many tools and
techniques for prototyping. The best thing to do is look at the
different prototyping methods, analyze them according to your
product and organizational goals, and use what you can.
Interaction designers and usability specialists often break down
prototyping in terms of fidelity, specifically high
and low fidelity. Fidelity refers to how responsive a
High fidelity prototypes are "working" applications--you press a button and something happens. I say "working" because high fidelity just refers to something happening. It doesn't
mean that it really works, functionality-wise. There is an assumed
majority of smoke and mirrors. False back ends and embedded
screenshots are all fair game. The goal is to give a realistic
taste of what your application is going to look and feel like.
Low fidelity prototypes, by contrast, are non-functioning.
Examples of low fidelity prototypes are screenshots and sketches.
An extreme form of low fidelity prototyping is paper prototyping.
Obviously if something is printed on paper, buttons aren't going to
work, at least not yet.
High Fidelity and Java
If anyone has ever asks you to do a screen mockup in Java, you
are building a high fidelity prototype. As a Java developer, you
probably tend to lean towards this approach, because it's what you
know. That's not necessarily a bad thing.
- Like the final product.
- Good for stakeholders, venture capital, etc.
- Give you a feel for the technology while designing.
- Lower design risk.
- Sometimes a good option for modification to a current
- False sense of completion.
- Time consuming.
- Difficult to change.
- False sense of security.
- Time sink! You can spend all your time tweaking the prototype.
It's hard to make a hard split.
If you decide to go with high fidelity Java prototypes, there
are a couple of things you can do to mitigate some of the larger
risks. Consider the false sense of completion as an example. First,
you could do a watermark with PROTOTYPE in big bold
letters plastered on your application. Watermarks and their
implementation are explained in detail in " "http://today.java.net/pub/a/today/2005/07/12/visualizations.html">Interaction
Happens: Thinking Graphically." Figure 1 shows the Java Web
Start management application with a watermark indicating that it is
"A watermark to reinforce the prototype status" />
Figure 1. A watermark to reinforce the prototype status
Believe it or not, sometimes this kind of reinforcement alone
can remind your stakeholders and users that this simply isn't the
real deal yet. If that's not enough, you can go the extra mile and
give the Napkin look
and feel a shot. This is a Swing pluggable look and feel (PLAF)
that makes your applications look hand-drawn. Figure 2 shows a
screenshot of Sun's SwingSet demo in the Napkin look and feel.
HTML can be an interesting choice. It runs in the browser, so
all of your users, testers, and stakeholders can use the
application before you figure out how your installations are going
to work. Also, a lot of people in this day and age are familiar
with at least basic HTML, and therefore non-programmers at your
company could probably work on the prototype a bit. There are also
a number of tools for building websites at your disposal:
Dreamweaver, FrontPage, etc. If you're building a web client, this
can probably work. If you're building a rich standalone application,
you could run into some difficulties prototyping as a thin client
and building as a standalone application.
Another option would be to prototype in another high-level
language like C++ or .NET. The problems here are very similar to
prototyping in Java, except that you have the extra complexity of
managing a different development environment. That can be very
resource-expensive. Also, all you're really saving is the demand
that you turn your prototype into production code. At the same
time, you run the risk of someone doing that anyway, then all of
the sudden you end up writing your application in an entirely
different language. Stranger things have happened.
At its most simple, a low fidelity prototype is something that
doesn't run. This could be anything from a screenshot to a napkin
drawing. Low fidelity prototypes are great because they are faster
to develop than high fidelity prototypes. On the downside, they
sometimes leave a little to be desired in communicating the interaction
of your system. Also, your prototype idea might not be completely
finished, and that might be OK. You may have a few flows that are
yet to be analyzed. It's much harder to hide such issues with a
high fidelity prototype.
- Quick to make.
- Fast and easy to change.
- You can leave more design unfinished.
- Usability testing more difficult.
- Stakeholders may be less comfortable with this.
- Easy to miss flows that would be obvious with a high fidelity
Wireframes are the extreme form of low fidelity prototyping.
Simply put, wireframes are black and white outline sketches of an
application. On the upside, they are the quickest to make and
assume the least about the final application product. On the
downside, they can be hard for new users or application
stakeholders to wrap their heads around. Figure 3 shows a fictional
wireframe prototype of Java.net if the "Community" link were
replaced with a new "Blogs" link.
Figure 3. Java.net bloggers page prototype, wireframe style
Use wireframes when:
- You are brainstorming.
- You don't care about the finished look as much.
- You have visionary stakeholders that don't need to see the
- You are doing rapid internal releases so you don't need all
design completed upfront.
Screen Capture Mockups
For lack of a better term, "screen capture mockups" refers to
making a realistic-looking picture of the final product using a
graphics application. This is a middle ground if you want a little
more realism than a wireframe prototype, without going to a
full-fledged high fidelity prototype. These often work well when
you're taking an existing system and making enhancements that don't
require high fidelity prototypes. Screen mockups might be a good
choice for the new blogs page prototype on Java.net, since it's
already live. This way, you can take a screen shot of the current
Java.net and use a graphics tool like Photoshop to add the new
page. Figure 4 shows a Photoshop-edited screenshot of Java.net with
the new fictitious "Blogs" page. Notice that all of the content is
in place. It looks exactly how it would look if it were real.
Remember that these techniques are not mutually exclusive.
Imagine a scenario where you plan on using wireframe prototypes for
a series of usability tests. Stakeholders are nervous and anxious
to see the final product. You could always run the usability tests
with wireframes and create a select few full screen mockups that
look as if they are screenshots from a finished product.
As with the high fidelity prototypes, I can't stress the
importance of reinforcement of the prototype status. If your screen
mockups are good, someone might think that your screen mockup is
actually a screenshot from a working product. I've gotten
in the habit of always using watermarks on screen mockups when they
leave my desk. This reminds people that it's not a finished
product. Notice the "prototype" watermark.
Use screen mockups when:
- You are testing your product for marketing purposes.
- You are testing with users that might be uncomfortable with the
unfinished look of wireframes.
- You are building a very graphics-intensive application (graphs,
- Your management wants a better feel of the overall appearance
of the application.
Be aware that some don't make a distinction between what I'm
referring to as wireframes and screen mockups. I have often seen
realistic-looking screenshots referred to as wireframes. I think
it's important to make a distinction between these two types of low
fidelity prototyping, since they have different benefits and
One of the common objections to low fidelity prototypes is
usability testing. Carolyn Snyder explains an interesting approach
in her book "http://www.paperprototyping.com/about.html">Paper Prototyping,
which is also the term for prototyping a working system with only
paper. Imagine you're testing the navigation of a website. There
are a finite number of pages in the site. You could then test the
navigation by asking them what they would click on, then replacing
the page printout in front of them with the page in the web site
that they would have navigated to if they had actually clicked a
button. This way, you can still test workflows and navigation
without building a high fidelity prototype, or even running a
computer in a usability test! This can be powerful, not only because
it gets people's heads out of the computer, but also because it
makes logistics easier--all you need is a couple of paper
printouts to run your test.
There are a number of applications that ride the line between
high and low fidelity prototyping tools. These are mostly
applications that are built specifically for prototyping. A good
example of this is Visio's application builder. It puts a suite of
Windows components at your disposal: buttons, scrollbars, window
frames, and more. What's more, you can build multiple screens and
connect them together by assigning actions to the components. This
way, you click on a button and you actually move to another screen,
giving the impression of real functionality.
The upside of this is that you get some of the benefits of a
high fidelity prototype (realism, for example) while bypassing some
of the more serious problems like having a manager demand that you
put prototype code into a production application.
You can't build a real working application in Visio's
application builder, but you can make a semi-decent, semi-high-fidelity prototype for basic applications. In practice, I've always
shied away from this approach because of its inherent limitations.
These prototype builder applications usually work for basic
applications. But as soon as you want to do something out of the
norm (like a custom graphical data display, for example), these
applications can run into difficulty. And that doesn't even account
for the learning curve for a custom prototyping application that
doesn't have proven longevity. Even as I say that, I think this is
an interesting space to watch. There could be a great prototyping
tool developed in the future that'll solve all of our little
interaction designer woes.
The first step in prototyping is trying to figure out what you
want to accomplish. Are you just getting stakeholder buy-in?
Helping your analysts visualize the system to help them gather
requirements? Screen mockups or wireframes might do the trick here.
Then consider your corporate climate. Do you work at the type of
place that would make you put high fidelity prototype code into
production? If you do, stay away from high fidelity prototypes. Or
at least make it clear with a watermark or the Napkin PLAF that the
prototype is not a real application. Finally, consider the project
you're working on and what it needs. Are you testing website
navigation? You can do this pretty effectively with paper
prototyping (wireframes or screen mockups). Or are you testing
marketing strategies and overall effect? In that case, you might be
better off building a basic engine with several skins and testing
them once your project is getting closer to completion.
When choosing your strategy, just consider all that you want to accomplish with
prototyping, your corporate climate, and your specific project. Consider the strengths and weaknesses of
each approach. And then come up with a plan using one or more of these
strategies. In general, I always suggest leaning towards the least
work in your prototypes. Favor low fidelity over high fidelity, and
wireframes over screen mockups. You want to spend as little time
prototyping as possible. The more detailed you get in your
prototypes, the harder they are to make, the harder they are to
change, and the more expectations are created.
Happens: Thinking Graphically"
Prototyping: website for Carolyn Snyder's book of the same
Prototyping: Getting User Data Before You Code," by Jakob
|width="1" height="1" border="0" alt=" " />|