Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

Understanding the Relationship Between Website Prototyping and Design

What is a Prototype?

In the past, I often would describe a website prototype as a plan for how a website works, not how it looks. While, in a sense, I still think that's true, I've come to realize that it's actually pretty confusing, don't you think? Especially since we go on and on about how sitemaps and wireframes are inadequate website planning techniques because they can't be experienced interactively, like a website. But a very big part of the web experience is visual! Every aspect of a website's structure and functionality is represented in some visual way by its prototype. With that in mind, it's much easier to see how the distinction between prototyping and design is fuzzier than I'd thought.

So, to better describe what exactly a website prototype is, I'd like to start by drawing a pretty simple analogy: Just as architectural plans use a consistent visual language to describe buildings, prototypes use a consistent visual language to describe websites. In both cases, there are many good reasons for the consistency part. Architects are trained to read plans and discern critical specifications from them that are later translated into three-dimensional structures. Likewise, website developers are trained to interpret prototypes and translate their specifications into functional code. You could say that the use of conventions make the plans look very similar, but that doesn't stop the results from being quite distinct.

Here's an example (FYI, it's going to involve a bit of scrolling):


See what I mean?

For designers, rather than seeing the prototype as a document that imposes limitations, I think it makes more sense to see it as one that enables creative freedom. Believe me, I'm not trying to spin this. To milk my architecture analogy just a bit more, imagine if blueprints didn't exist. Without them, it would be amazing if buildings were built at all, but it would be even more incredible if the ones that did remained standing! In the same way, prototypes provide a structure that ensures a website is even possible. No matter how great a design might be, if it's not possible, it's useless.

Essentially, what I'm saying is that a good prototype wants to support good design, not step on its toes. But I realize I'm going to have to get a bit more into the details of how prototypes communicate in order to build my case, so bear with me...


The Language of Prototypes

The first priority of a prototype is to accurately represent the information a website will contain. That includes structural information—like the hierarchy of pages and sub-pages that make up a website—as well as content, which includes everything from the words and images displayed on pages to the logic behind content relationships and other functionality. In other words, a prototype has a big, big job: communicating a ton of technical information that will be understandable to everyone involved in the project—the technical and the non-technical—without using technical language (or for that matter, even working at all). Let me explain...

At the time of this writing, sunrise is expected about 15 hours from now. Maybe if I'm still up then (working on this article, of course), I'll stop for a break and watch the sun come up. Buuuut, probably not. The reason I bring up sunrise is that it's a perfect example of phenomenological language, which is exactly the kind of language a prototype uses. If you speak prototype—which I hope you will by the end of this article—you speak phenomenologically, which is to say, you speak in a way that describes experiences. We know that the sun doesn't actually rise, but from our subjective vantage point way down here on Earth, it looks like it does. The Earth would have to be much, much smaller in order for us to experience its day-long spin. So, despite our modern enlightenment, we still say "sunrise" because it's a whole lot clearer (and less pedantic) than saying "the time in the morning when we've spun around enough to see the Sun again."

Prototypes describe what it will be like to use a website—that's the phenomenological part—in a way that satisfactorily engages and prepares the client, without confusing anyone with overly technical jargon. But that leaves one question: if the prototype doesn't use technical language, how does a developer know what to build?

To answer that, let me first show you an example of a prototype:


The first thing you probably noticed is that the prototype is mostly gray. We do this intentionally just to make sure that nobody gets sidetracked by any aesthetic hang-ups—at this point, we're not interested in whether the prototype is pretty, just whether it works. The second thing you may have noticed is that the prototype looks like a website...well, sort of. The page is certainly layed out like a website would be (and, were this an actual prototype, you could navigate from one page to another), but some things are specific while others are generic. For instance, the main navigation has what look like specific page names in it, but other parts of the page have generic titles like "Blog Post Title."


These are the brass tacks of the language of prototypes. In general, some aspects of the site will be very specific, and the way the prototype describes them will reflect that. So, from this image, the main pages (and their sub-pages) are named, and though that doesn't necessarily mean those names cannot be changed once the website is built, they're probably not likely to do so very often. On the other hand, the blog post that is featured on the homepage is likely to change very often. By using generic language, as opposed to prototyping a specific blog post title, the prototype is communicating to the developer that the site should be built in such a way that the end user can add new blog posts and name them whatever they wish. Just like "lorem ipsum" dummy text generally means "text will be here," generic titles stand in for types of content that are meant to be editable.


The Structure of Prototype Pages

Here is where I think most of the fuzziness between prototyping and design comes in to play. Because the prototype must communicate the website experience (that phenomenological language again), it has to work like a website—which means you need to be able to click from page to page. But in order to work like a website, it has to look like one, too. That's why sitemaps—they don't look or work like a website—and wireframes—they look (in a Flatland kind of way) like websites but don't work like them—fail to communicate anything useful about, well, using websites. Where I'm heading with this is that since prototypes need to look like websites, they can't look just any way. The honest truth is that building a prototype does involve a kind of design.

The kind of design I'm talking about has to do with communicating the priority of information on a page—or, for short, information design. The prototyping process involves returning to two core principles over and over again with every information design decision that the team makes:

  1. What is the purpose of the website, and
  2. For whom?

The answers to those questions should lead to very focused pages with a clear sense of priority. This is often manifested in visual decisions, such as the relative sizes and positions of elements on a page or typographical details if the volume of information on a page warrants it.

Let me unpack this with another example:


I created these simple mock designs for my example prototype in order to make a simple point: Though the prototyped homepage has a very deliberate layout in which the information on the page has been clearly and intentionally ordered, the spectrum of possibilities for what the final website can look like is still wide open.

Both examples take many liberties with elements of the page, but neither remove essential information nor disrupt the order of the information in a way that fundamentally changes the focus of the page. The interactive slideshow element, which occupies about 3/4 of the horizontal space at the top of the page, is still the most prominent visual element in both designs, even though Option 1 has changed its size. The sign-up form is not fundamentally affected by being relocated, nor has the choice to limit the number of blog posts on Option 2 significantly altered the overall priority of blog content on the page. Aside from these specific layout choices, Option 1 and Option 2 represent very different creative directions even though they share the same prototype.


Designing Navigation Menus

Navigation menus are probably the most important user experience tool a website has to offer. Without them, most websites would be completely disabled—leaving vast amounts of content simply unreachable to users. But even if a page contained enough links in the content to make it possible to reach every other page on the website, a clear, structured navigation system also communicates the overall order and intent of the website. Depending upon how they are constructed, a user could potentially get an overview of all the pages and topics a website contains without actually clicking anything. For browsing-oriented users, this is critical to their experience.

Usability studies have continually affirmed that the conventions you are probably used to—horizontal navigation bars with interactive, vertical sub-menus—are highly effective and usable as they scale in complexity. This is precisely why that style of navigation is the default for our prototypes. But that doesn't mean that every site must necessarily employ that style of navigation menu. Our own site is in good company with others that have used a simple list structure, for instance, rather than the standard horizontal navigation. In our case, we felt that our site did not have a deep enough structure to merit anything more complex, and have had that decision continually affirmed by analytics data since.

Typically, a prototype will preserve the standard menu approach, but include a note to the developer working on the project describing how the design will alter the final menu interface. As long as the conceptual structure of the website—its top pages and their sub-pages—isn't fundamentally changed, the interface is certainly negotiable.

Here is an example of a currently active project where the designer planned to implement a navigation interface that was slightly different than the prototype. Below that is an example of how the drop-down menus of a standard navigation bar can be handled differently:




Repositioning Forms

Our approach to forms during the prototyping process is similar to our default approach to navigation menus—to follow established conventions that ensure the most stable user experience possible. Because heat map studies continue to affirm left-to-right zigzagging user patterns on web pages, form widgets are most commonly placed on the upper right-hand portion of web pages. It's a bit of a chicken-and-egg scenario, actually. Since content-related tools and resources are typically found on the right side of web pages, users intuitively return to that location as they read through pages. So, it makes sense to continue to place utilities in that space. But just because the convention is securely rooted in usability data doesn't mean there will never be good cause to do something different.

I imagine that as we continue to learn more about how to make forms and other calls to action more user-focused, the convention will surely be tested and perhaps fundamentally changed. Meanwhile, implementing these kinds of touchpoints in the mobile context will also generate a feedback loop that will begin to shape behavior in other contexts, especially back on our desktops. That will be a trend to watch.

Below is just one example of how a designer tried a different approach to positioning a form element. Again, like designs that alter navigation interfaces, no information has been removed or fundamentally changed about how the form works. But it's position now makes better sense given it's priority as a global call-to-action.



Sub-Page Templates

In the past, a typical web design project would involve the design of a homepage template and maybe one or two sub-page templates that would be used for the majority of the website's content. Today, the number of uniquely designed templates is growing as our understanding of persona-based user interfaces (and overall sophistication of approach) increases. Specifying unique templates shouldn't wait for the design process, though. This should happen during the prototyping process as well. In fact, a typical prototype today can include anywhere from 30 to 50 unique pages. That's quite a lot when you consider that you only have to prototype an example of a blog detail page once!

But even unique pages can share the same layout. The point to emphasize here, again, is purpose. What is the page for? What information needs to be on the page in order to make it successful? As you work your way down, so to speak, in a website's structure, sub-pages should become more and more focused. A third-level page in a website's overall hierarchy—naturally more of an endpoint in a user's flow than something higher up—should provide fewer, more specific options. That means that top-level landing pages—those that provide overviews of product families, service offerings, and the like—will tend to be much broader topically, and consequently, a greater information design challenge. Those pages, just like the homepage, should be prototyped as specifically as possible in order to ensure that the information design problems are being solved before the visual design process starts.

Below are several examples that will shed some light on various approaches to high-level landing pages from prototyping to design. In the first case, the design of the page takes a more literal approach to interpreting the prototype, which was done with a higher degree of precision given the capacity issues it faced. In the second example, the designer was afforded far more latitude given its lighter load of content and some particulars related to how interactive features are working on that page.





The Devil is in the Details

Aside from the confusion around how a page's structure should be interpreted and handled by designers, there are a couple of minor details I wanted to point out that are often easily overlooked in that fuzzy place between prototyping and design.

The first has to do with how different areas of a website will expand to fit changing content. Remember, if your website is using a CMS (I really hope it is), content on just about every page of your site is likely to change. But as powerful as a CMS is, it can't change graphical elements on the fly. Imagine a sidebar that you've designed to have an uneven edge. In your composition file, it looks great, but as soon as the content is actually changing and growing, you're likely to have a problem. How will that area stretch to fit? For dynamic content areas like this, the best approach is to keep jagged areas limited to the fixed portions—often the top and bottom—and design the flexible ones to have backround images that can repeat as the vertical space expands. I've included an example of this below.

The second also has to do with background graphics, but this time those that fill the browser window behind your website's main content area. Using unique images here, as opposed to solid colors, can be a great way to add space and mood to your design, but you want to make sure that your images are wide enough to fill even the largest possible horizontal resolution, or have an edge treatment that enables them to gracefully fade to a solid color or texture. Even if you have created background imagery that does anticipate wider screen resolutions, try to make the transitions as subtle as possible. I've included an example of this concept below, as well.




Parting Notes

You've made it to the end—congratulations! Even though this page is jam-packed with information (and must be one of our longest pages so far), I feel as if I've barely scratched the surface. While most of the things that tend to cause confusion for our design partners are covered here, there are so many details and variables that are relevant to the prototyping/design relationship that aren't.

So, let's use the comments section of this page to handle any questions you may have about the things I may not have covered—or the things I did. I'll respond to each one. And if you'd rather ask a question in private, you can contact me directly here.


Andrea at ProtoShare | April 7, 2011 1:09 PM
Interesting thought on the difference between a wireframe and a prototype. I would say the example of your prototype above (being mostly gray, with some boxes and text) would be considered a wireframe. It tells me the basic layout of where items will be on the page.

But I would also say it is a prototype. Maybe it can be compared to "a square is rhombus, but a rhombus isn't a square." A wireframe is a prototype, but a prototype isn't a wireframe. (I bet that will have arguments on both sides of the table...)

However, a prototype is certainly more valuable because it helps us understand a page's purpose (as you put it), or functionality and goal.

The way we describe it is that you need to know how you plan to layout a page (hence the wireframe), but you need to take it to the next step, which is prototyping. How will the page or application act, what is it's goal, etc.

It's good to gain other people's perspectives and tactics on the topic, so thank you.
Christopher Butler | April 1, 2011 8:03 AM
Andrea: Thanks for reading and your enthusiasm around the subject! About wireframes, though—we don't actually create them at all anymore. We just go right into prototyping. Sometimes, an agency partner or client will have some wireframes already created going in to the process with us, but we've found time and again that the information they contain tends to be completely rethought once it is moved into an interactive environment.

Allie: Better late(r) than never! Thanks for reading and commenting!
Allie | March 31, 2011 9:36 PM
Took me a while to get through this but it was worth every minute! thanks for all the detail and great explanations, especially the floorplan-to-house analogy!
Andrea at ProtoShare | March 31, 2011 11:11 AM
Another very informative article; thank you.

"You'd potentially have twenty to thirty pages tacked up on the wall, perhaps arranged in a way that indicates an assumed flow of use. Without being able to observe actual use, that flow would be no more than an assumption, and probably a very incorrect one at that. As far as realistic use is concerned, a wireframe will not provide any insight. All you can really do is look at it and hope for the best."

In terms of wireframes, I couldn't agree more with your words. Wireframes are an important part of the planning process - just like site maps are - but you can't just stop there. As you so clearly illustrated, everyone who reviews a static wireframe inputs their own interpretations of how the website will actually work. However, that's not the only drawback. If someone can't experience the intended flow, they don't know what questions to ask about that flow. They don't have valuable feedback to give, just that they assume it will have all the pieces they feel are necessary to that action or page. But if they can click on pages, type in the form fields and move to the next step, they can tell you if you are missing a key element, have too much information, or that the process is clunky and the abandon rate will be high.

We need wireframes to get to the prototyping stage and we prototype so that we can iron out the wrinkles before coding the website. By planning more thoroughly we save time in development and save the client from surprises that can potentially bruise the relationship. Early understanding is key and understanding is more than a visual element.
Christopher Butler | March 31, 2011 8:14 AM
Michael and Neil: I'm glad you both enjoyed it. Thanks for taking the time to say so!

Jake: I think I understand what you're getting at, and hopefully I can clear it up. The first thing I didn't really get in to was who does the prototyping. At Newfangled, our Project Managers actually create the prototypes. Throughout the process, they consult the client, developer and designer, so it's very much a collaborative process. But it doesn't involve the kind of redundancy for designers that you described.

As for whether solving the wireframe problem with prototyping just creates a new problem of it's own, I'm not convinced it does. I didn't go much further than to say that sitemaps and wireframes are not adequate planning documents because I generally assumed that is common knowledge at this point. But as you point out, many people still use them for exactly that and don't build interactive prototypes. So, let me say this...and bear with me, this is going to take a few minutes:

A sitemap is simply an outline of the pages a website will contain. Think about what information an outline actually provides. If the content of this article, for example, were reduced down to an outline, it would contain an overview of the subjects I've covered, but the majority of the article's insight and value would be lost. Now, imagine if you had the outline I created for this article before I actually began writing it. That outline would likely be substantially different from an outline "reverse-engineered" from the finished piece. This is because an initial outline, as all site-maps created for planning purposes are, is an impression of a website’s structure and content that has not yet been tested by actual web-based interaction. As a planning method, they are fine places to start—like a cocktail napkin might be for logo designs—but little more.

What about wireframes? Albeit slightly more sophisticated, wireframes are just as ineffective a website planning method as sitemaps. Rather than specifics, wireframes might generalize things and substitute generic filler copy for the content that will eventually occupy the page as a way to preserve the conceptual limitations of the planning phase—as if to say, “these pages are telling you how things will work, not how they’ll look.” But the result tends to be much more confusing than helpful. Imagine reviewing a set of wireframes for even a modestly sized website. You’d potentially have twenty to thirty pages tacked up on the wall, perhaps arranged in a way that indicates an assumed flow of use. Without being able to observe actual use, that flow would be no more than an assumption, and probably a very incorrect one at that. As far as realistic use is concerned, a wireframe will not provide any insight. All you can really do is look at it and hope for the best.

The information you really need from the planning stage is necessarily tied to use. Sitemaps and wireframe are incapable of communicating anything even remotely close to the experience of using a website. After all, they are translating an interactive experience through a static medium. All kinds of metaphors can expose the absurdity of this, but one that really emphasized this point for me recently came after a visit to the American Natural History Museum, one of my favorite places to visit in New York. Among their permanent collection is a series of dioramas depicting animals of all kinds in their natural habitats. I could spend hours looking at these works of art; they are beautiful and astonishing in their detail and care. But despite all the detail, they still leave out more than they contain.

As I stood and gazed at the illusion before me—two brown bears, one standing, the other on all fours considering the trout it had just pulled from a nearby stream, the dirt of the small shore, the golden plains grass around them, and of course the snow-capped Alaskan mountains far in the distance behind them—I realized that everything else I was experiencing—the dry cold air, the gurgling of the river, the smell of the grass and dirt, and the fear of these menacing, powerful predators—was filled in by my imagination. Yet, it was this content—the visceral, sensory information—that provided the experience I remember by infusing it with meaning. Triggered by the symbols depicted in the diorama, I invented the experience for myself, which will remain true to me until I set foot on the actual soil of the Alaskan Brown Bear’s habitat and am corrected by reality. (Someday...)

This is exactly what happens (maybe with a bit less excitement) with wireframes. They attempt to capture the essence of a website in a frozen and generalized format, leaving the viewer to fill the rest in with his imagination. But that’s what should really scare you: if everyone lets their imagination supply the experience, then everyone will expect a different website. No website built from such general specifications will satisfy anyone’s expectations, even the realistic ones! So, if paper sitemaps and wireframes are no good for website planning, what is? I'll give you one guess... ;-) Thanks for the question!

Andrew: Very true. No plan = big mess. Buuuut...I can't pass up an opportunity to discuss an obscure paranormal reference, so... The Winchester Mystery House! The real story behind the house is that the bereaved Sarah Winchester sought consultation from a "medium," who instructed her to begin constructing a house for the spirits of those who deaths were related to the Winchester rifle in some way. The catch was that she could never stop building the house...or so the "medium" said. Another story claims that it was a message from her deceased husband (again, delivered via "medium") that an unending building project would be a good thing for her to do. Anyway, the moral of the story seems to be pretty straightforward: Don't consult "mediums."

J.T.: The feedback we've received has been nothing short of wonderful. Not because it's all praise, but because it's a mixture of affirmation and constructive criticism. We believe that there will always be room for improvement—our company is a work in progress, too—and we're eager to pursue that progress in any way we can. Fortunately, our agency partners are a generous and insightful bunch!
J.T. | March 30, 2011 9:24 PM
Really dug this post!

I'm definitely going to use your "language of prototypes" explanation with my clients-that just nails it in a way that anyone can get.

Also I just wanted to say thanks for being open-minded about your client's feedback and taking it into consideration when writing content for your site. I can't think of many examples of that that I've seen before. It's pretty cool actually.
Andrew | March 30, 2011 6:46 PM
Thanks teacher, another great read.

I heard of this one in an introduction to another type of information design -specifically business process architecture:

A physical example of where architecture goes bad is the Winchester House. (Yes, Winchester of rifle/gun fame)
The widow Winchester had to keep building on her house to keep the ghosts away.
She used dozens of architects, hundreds of builders, all of her life and all of her fortune.
The end result is "interesting"
- staircases to nowhere
- windows in the floor
- ten chimneys but only 7 fireplaces

The moral of the story is the same as yours - start with a plan or end up with a monstrosity.
Jake | March 30, 2011 6:45 PM
Just to play devil's advocate...

The prototype is supposed to alleviate confusion that sitemaps and wireframes create for the client, but it ends up creating confusion for the designer. That makes me think that there has to be a better solution that suits everyone. In the projects I've worked on, wireframes haven't caused any problems on either end, so after reading this and getting the picture about how prototypes can cause problems for designers, it makes me want to stick with my wireframes.

On other point...

You were mentioning how information design precedes visual design. But that's what designers do, so it seems strange to have them do one part of their job in the prototyping, but holding back on some of it, then finish that and move on to only the visual part. A designer who knows what he or she is doing should be able to employ info design skills when creating layouts. That seems more efficient to me, anyway.
Neil Renicker | March 30, 2011 4:01 PM
Thanks so much for the read. I learned a lot, and appreciate the good visual examples to support your article. Keep it up!
Michael R | March 30, 2011 2:20 PM
Good read!
Christopher Butler | March 30, 2011 1:41 PM
Desmond: There's a good book on eye-tracking/heat map studies by Jakob Nielsen, called Eyetracking Web Usability. The page I linked to includes a lot of information on the book and an overview of how heat-mapping works.

On the topic of auditing websites, next month's newsletter is going to be on a stripped-down/simplified approach to website usability testing and will (hopefully) include some example videos of user tests.

Thanks for reading, commenting, and sharing this on Twitter!
Desmond Williams | March 30, 2011 11:46 AM
Great information as always. Creating an intuitive user experience within a website that warrants quite a bit of navigational links is a challenge. I find heat map studies and user experience data very interesting and a good way to help take an audit of your website (which, for me, is constantly).

Thanks again for the read.
Christopher Butler | March 30, 2011 10:49 AM
Mac: I'm glad it was helpful. There are certainly plenty of "don'ts" to consider, but my sense was that designers have heard many of them and, as a result, tend to approach the process with a heaviness that is almost pre-defeat, so I wanted to place a greater emphasis on the "do's" instead. Thanks for reading!
Mac Heller-Ogden | March 30, 2011 10:04 AM
Great article-thanks for sharing! I often struggle to communicate to my designers the freedoms that they when interpreting the wireframes and prototypes we hand-off to them. You've really hit the nail on the head with some great examples to boot. Much appreciated reading, as always. Keep up the good work!
Christopher Butler | March 29, 2011 1:30 PM

I received a great comment from John Kuefler, EVP and Chief Strategy Officer at Callahan Creek (and the originator of the feedback that prompted the article). We emailed a bit around it and I suggested we include it in the comments here, to which he agreed. Here's his comment:
So, did you see the sunrise, or were you still slumped over your computer?

Great job as always. I think this should be very helpful to novice web designers or those going through the process of translating prototype to design for the first time.

The architecture visual analogy was perfect. Marbles Kids Museum was a great example of stretching the prototype during the design phase. After the Imprivata "literal" example I expected more of a departure from the prototype for the other example - more divergent than Rhino (if you have it).

It will be interesting to see what comments you get. Seems like this could be a new chapter in the next edition of your prototyping book.
As I read John's email, I started thinking about sites we've launched recently that might provide a better example of a divergent sub-page template design. After all, John is right, the Rhino example isn't that divergent. But then I had another thought, and this is the one I'll probably stick with for the time being: The simpler a page is in terms of information, the more latitude its corresponding design will have. Which means the inverse is also true: The more complex a page is—again, in terms of information—the less latitude its corresponding design will have.

I chose the Imprivata example intentionally to make the point that a page with a significant burden of information will require a greater degree of specificity in the prototype, which, in turn, will result in many design decisions being made in advance of the visual design process. That makes sense, because information design should steer visual design. On the other hand, a page that has a very minimal burden of information—the kind of page that might be described as "just having an open content area"—wouldn't necessarily have the kind of latitude that results in a wildly divergent looking design. The more that's going on visually, the more—presumably—is likely going on programmatically. If that's not the case, say, in an example of a simple page resulting in a very divergent design, then it's likely the design is introducing new information to the page that should have been handled in the prototype. Or, the information that is "divergent" is part of the overall site's design. Neither case is likely, though, to result in an "opposite" to the Imprivata example.

In other words, I don't think an individual page's design is ever likely to be radically divergent from it's prototyped counterpart. Core template differences, however, like Biro's navigation example, are possible.

I hope that makes sense.

Thanks, John, for reading and, of course, all of your truly valuable feedback!

↑ top