Considering Prototypes

June 15th, 2010
Published on
June 15th, 2010

Although prototypes have been used in other domains for quite a while, their value to the design & development of websites has only recently taken shape, so to speak. Modern websites take a lot of work. Whether the ramifications of their creation are uncovered at the outset—typically with design and development considerations—or in the longterm—how is archived content going to be accessed? is this the best way we could have designed this?—building a prototype allows us to explore natural omissions made during the design process in an efficient, cost–effective way.

So, what is a prototype? Generally, a prototype is rudimentary version of something designed to exhibit both form and function in a realistic way. Think of the miniature models made of skyscrapers. By definition, prototypes aren’t perfect because their purpose is pragmatic; they elicit feedback.

A variety of considerations go into the creation of prototypes: where do they live in the development process? what kind of context(s) do they facilitate? and how do we build them? Despite these vagaries, prototypes yield a variety of benefits to those that put them into practice.

Agile, iterative development

Although the word prototype is often given a negative connotation (usually seen as “throwaway” work), html prototyping is merely a consequence of agile development—a development methodology generally held in high regard.

During my work with an agile consultancy, our clients (mostly startups) came to us with fantastic ideas. The only problem was that these ideas were unproven and would take months (not to mention lots of money) to develop. The question I frequently explored was this: how could I present my clients with their minimum viable products sooner? In other words, how could we collaboratively develop a prototype (or perhaps even a sketch) of their ideas?

Unlike traditional prototypes that are simulated or built with different materials altogether, websites and web applications are different; their prototypes can be developed and deployed with real–world, production–quality technologies such as HTML, CSS, and jQuery.

If a database–backed interaction required a proof of concept, I found myself turning to content management systems such as Drupal, ExpressionEngine, or even WordPress in order to explore the problem space (in addition to considering the database structure that might be required). UX Designer Cennydd Bowles describes some ramifications, both positive and negative, of this approach in his article on agile design.

Regardless of the technique employed, the goal is the same: to obtain a more accurate rendering—and, hence, understanding—of what the final website will look like and how it will function.

So bring on the context

Unlike static wireframes, dynamic prototypes create context. If properly executed, those who engage with them tend to ask questions or make remarks that they simply wouldn’t from considering alternate design deliverables. As a consequence, I personally favor prototypes when it comes to both user testing and user research.

If a prototype doesn’t work the way the team anticipates, it can quickly be discarded and replaced. But before we task ourselves with changing a prototype’s visual or interaction design, we do well to give consideration to other factors related to the experience we’re creating. In Paula Wellings’s article Beyond Prototype Fidelity…, Paula explains how a number of related factors affect prototypes—not just the fidelity of the prototype itself, but elements such as environmental and social fidelity. She goes on:

Similar to how prototype fidelity can be dialed up or down to give the project the direction it needs to move forward, social and environmental fidelity can also be used strategically.

For example, at one stage in a project for a new mobile service, it might benefit the project to focus primarily on the role of the environment on the design.

  • Social fidelity [low]: low focus on friends, family, mobile calls
  • Environmental fidelity [high]: spend the day with a research participant, going where ever they usually go, or follow the typical route without participant
  • Prototype | Intervention fidelity [low]: mobile device with a screen that is a stack of post-it notes, interfaces flipped or drawn at appropriate times.

Spending a day in the field doing this sort of design work can illuminate environmental factors that can only be imagined from the office.

Paula Wellings

In other words, we must ensure that our prototypes aren’t myopic. Although killer design does compel users, that design could prove useless if it’s going to be accessed on mobile devices. Informing design means we must inform our prototype’s context.


Prototypes should be, above all, quick and painless to create. So, just because HTML might be the easiest way for digital designers or developers to create rudimentary solutions doesn’t mean it works that way for our clients. Sarah Nelson, principal of User Experience at Hot Studio, ruminates further on this concept— namely, that of a participatory, collaborative, communicative design process in her presentation 10 Secrets from a UX Design Strategist’s Toolbox.

In his prototyping book, Todd Zaki Warfel provides readers with a wide variety of tools to prototype with, including sketching, paper (and other analog methods), PowerPoint & Keynote, Visio, Fireworks, and Axure RP Pro, in addition to trusty HTML. Consider them all. If one method helps our stakeholders more clearly articulate their ideas, it’s arguably more valuable than creating an inaccessible prototype in (what could easily be considered) a foreign language.

An organization that practices both prototyping as well as agile development promotes internal synergy between designers, developers, stakeholders and users alike. Testing prototypes and developing in iterations helps pace the team by first exploring the trail and then taking calculated steps. Far too often, we treat web development as a sprint rather than a marathon. It is the experience designer’s job, in part, to help everyone walk the steps of the experience they’ll create before they run—especially when they’ll be doing so in tandem.

Final thoughts

With regards to development for the web, prototyping is rarely considered; in fact, it’s often forgotten until after the initial website launches: We prototype solutions for A/B Tests, but not for key features.

When designed early and often enough, prototypes generate context and questions in time for an agile team to answer their challenges. As those who design experiences, we must promote prototyping as a part of the design process in order to iteratively improve the experiences we create.

Although no one can meet the most exacting business demands—free, perfect, now— prototypes move our team in that direction. And that’s something clients, consultants, and users can all agree upon.

Further reading

Additional resources