Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

Prototyping’s Resurgence: Communicating the Designer’s Intent

by Jared M. Spool
on March 8, 2012

Interaction design is facing a paradox because of two seemingly conflicting truths. The
first truth, “Great design is done in the designer’s head.” Design is a thoughtful
activity. We sit and consider what we’re designing very carefully. If we don’t have time
and a place to think, the odds are we’ll arrive at a poor design.

However, that seems to be in direct conflict with another truth: “Design is a team sport.”
Today’s interaction design is so involved, so complex, that it can’t be done by one person
alone. Great designs come from teams of designers working together.

Yet we can’t shove the entire team into our head (or even part of the team, for that
matter). So how do we reconcile these two truths? How can we do the design in our head
while working as a team?

This is why prototyping is seeing a resurgence amongst interaction designers. I say
resurgence because for the last ten or so years, prototyping hasn’t been a popular design

Prototyping’s Early Days

Let’s set the wayback machine to the early 1990s, before the web gained its traction. In
these days, most of the interaction design work (though we didn’t call it that then), was
for software systems and packages. Prototyping was growing in popularity amongst designers
because it helped people see a design before the formal coding started and set the team
down a direction they might later regret.

In those days, the most popular tools were things like Microsoft’s Visual Basic (invented
by UX Superhero Alan Cooper) and Apple’s Hypercard. Visual Basic was a development
environment, but because it had a lot of built–in user interface components, it made
producing a working design mockup fast. Hypercard was a hypertext delivery system
(probably the most popular ever built, up until the web obsoleted all of them), also with
a great toolbox of ready–made UI components.

There were others too, like Dan Bricklin’s Demo, which made it easy to create simulations
of what the program would look like. However, our favorite back then was paper

The beauty of paper prototyping was how quickly a team could get a design working. All the
other tools of that day were solo activities — only one designer could work on the mockup
at a time. With paper prototyping, everyone could gather around a table and build out the
components of the design. Within minutes, the team could have a prototype they could use,
or even better, put in front of real users.

We used to run these workshops we called “Six Days” because, coincidentally, they took six
days to execute.

  • Day 1: Plan the project.
  • Days 2 & 3: Build a fully working prototype from scratch (often iterating a dozen or so times as we worked the kinks out).
  • Day 4 & 5: Conduct eight or so usability tests with the prototype, changing the design between each
  • Day 6: Document what we came up with by photocopying the design elements and making
    a walk–through video.

Teams loved the Six Days workshops because they weren’t sitting in endless meetings
hashing out abstract requirements and specifications. They were building stuff. It was
common for us to conduct a Six Days workshop as the project kickoff, with all the
stakeholders, developers, and QA folks building and testing the prototypes. The team would
end the exercise with a working prototype that had been vetted by a bunch of real users,
where they had identified all the big issues and solved many of them.

The Dark Days for Prototyping

However, all this prototyping activity started to take a back seat as web sites became the
big design activity. Content rich web sites don’t lend themselves to prototypes, mainly
for two reasons. First, content is hard to simulate. Sure, you can “lorem ipsum” your way
to heaven, but that doesn’t really give you a feel. Users can’t test a page with greeking
scrawled all over it.

The other reason was because the web had a very simple interaction model. In the
unsophisticated early browsers, you really only had links to pages to work with.
Prototyping a click of a link isn’t really necessary.

Designers created site maps and wireframes to communicate their intentions. These static
representations of the architecture and pages did the job. The practice of building
prototypes fell to the background.

Prototyping is Now Making a Comeback

Traveling back to today, we see web interaction has become far more sophisticated than the
early days. We can do so much on the page that we couldn’t do even five years ago. Instead
of the simple language of clicking links, we can now easily drag, fade, provide halo
feedback, and a million other subtle interaction nuances that make the design flow for the

Beyond the web, the ever–expanding range of devices are forcing designers to innovate new
ways of interacting with their designs. Integrating touch with gyroscopes, accelerometers,
GPSs, and other built–in devices creates a rich, complex design landscape. Every day, it
gets more complicated for the designer to imagine their design and communicate their
intentions to the rest of their team.

It is within this environment that we’re seeing a growing resurgence in using prototyping.
Prototyping helps the designer get the ideas out of their head and makes it available for
the rest of the team.

Today’s tools for prototyping have grown alongside the demand. Software tools, such as
Balsamiq, Axure, and iRise have come a long way from their Visual Basic and Hypercard
ancestry. They come out of the box, rich with built–in interaction tools for complex
design elements, such as the fashionable Coverflow display technique. Just grab an
element, drop it on your screen canvas, and you’ve instantly added the look and behaviors
into your design.

We’re also seeing a renewed interest in paper prototyping. While there have been some
attempts to provide pre-made elements for paper prototypes, the real value comes in just
sketching something, then “playing the computer” to make the interaction work. The
simplicity of the technique makes design a collaborative activity, encouraging the
inclusion of non–designers, such as support, QA, and even users, in the design
conversation. Suddenly, it’s easy to “try it and see.”

But the most interesting outcome of this new resurgence is the movement to design in the
browser. Because of the high-level toolkits and frameworks provided by JavaScript
libraries like jQuery UI, it’s very easy for a design to learn enough code to do magical
things. This isn’t production–quality code (prototyping never is), but it’s good enough to
show the designer’s intent to their team. And new libraries and plugins keep extending the
capabilities, while keeping the act of prototyping simple.

Designer’s Gotta Prototype

What we’re seeing in our research is that the best teams are spending time practicing
their prototyping skills, across the full range of tools. While some designers focus on
just one tool, the best ones learn to quickly create their designs from tools spread across the
range, from paper to jQuery. The designer who can work in any of the tools gets to pick
the best tool for the problem they are solving.

Speed and agility are the most important attributes any design team can have, even beating
out creativity and innovation. This is because a fast–moving process that iterates
frequently gets to take advantage of the natural evolution of the design, whereas a slow
moving process needs to discover innovation out of the gate, which is much more difficult.

We’re seeing that designers who grew up in the web-based wireframe days are finding the
transition to prototyping far more difficult than the new designers just arriving on the
scene. We think that as interaction design matures, that older group will struggle keeping
up if they haven’t mastered the range of tools.

Prototyping’s resurgence is putting huge demands on the established designer to master new
skills. But those demands pay off quick with a speed and agility to communicate their
intention and get their ideas into the world. It’s worth it.

Share Your Thoughts with Us

Are you building up your prototyping proficiency? What’s your journey been like? Let us know at the UIE Brain Sparks blog.

About the Author

Jared M. Spool is the founder of User Interface Engineering. He spends his time working with the research teams at the company and helps clients understand how to solve their design problems. You can follow Jared on Twitter at @jmspool.