How to Think About Website Prototypes (for Designers)

Posted inInformation Design
Thumbnail for How to Think About Website Prototypes (for Designers)
Prototyping for Designers

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):

Prototypes Use the Same Visual Language to Describe Different Websites

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?

Example Website 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 the example, 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 p
ages 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:

Comparing Layout Options with the Original Prototype

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.

There’s so much more to say about the interplay between design and prototyping—much more than this post can handle, I’m afraid. I adapted this from a longer article I published a few months ago called Prototyping for Designers, which has many more examples of information architecture decisions and how they manifest in later designs, so if this has struck your fancy I recommend checking it out.

>EXTRA: For web design tips, pick up Patrick McNeil’s book the Web Designer’s Idea Book, which provides inspirational examples of winning layout, color, and style directions.