Prototyping’s Resurgence: Communicating the Designer’s Intent

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 activity.

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 prototyping.

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 test.
• 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 user.

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.