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

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.

Related Articles:

ADD A COMMENT

15 COMMENTS

  1. Pingback: Week 6: Prototyping and Website Redesign_v2 | shuqi86

  2. Pingback: Prototyping for the Web | My process and I

  3. Pingback: Article III | yporcile

  4. Pingback: DesignBiz: The Tipsy Triangle of Software Startupdom — Imprint-The Online Community for Graphic Designers

  5. I knew that design of the website is very important but I didn’t know that there is website prototype. Reducing size prototype also improves the look of the website. Maybe I should try to check out if I have prototypes or not in my website.

  6. Pingback: Полезные ссылки выпуск №4 | Юзабилист

  7. Neal,
     
    For most of our projects, the prototyping phase is indeed the first big chunk of work. Some of them begin with a purely strategic phase that helps to solidify the direction, goals, and plan for the project, but there is not standard deliverable produced from that work–it really depends upon the project.
     
    I’m not sure if you followed the link at the end of this post to the expanded version on my site, but there I intentionally included many examples showing how the ways the prototype articulated page layouts further evolved in the visual design phase (which happens after the prototype is approved). The reason I wanted to show so many of those examples was to allay your main concern: that the prototype would prematurely lock in the client (and the designer) to design decisions. As I hoped I showed, that is certainly not the case. While some prototypes can have much more specific articulations of layouts–especially those pages with heavy informational loads–that in some ways pre-empt design, others do not and the designer has the freedom to order the page in the way he or she sees fit for the project’s needs.
     
    I think that also allays the fear of web design being reduced to merely the technical. For us, this couldn’t be further from the truth. If you were to observe our team going through the prototyping phase with an agency partner and client, I’m confident you would see it as a mostly strategic process–one that involves developing personas, doing market research, deep thinking about the technologies that will be used and the design itself, among much else–that results in a technical document that keeps the team accountable to a shared goal throughout the rest of the project. Because it’s such a richly textured and layered process, it really sets the tone for the remainder of the project and even the long-term client relationship. At the risk of sounding culty, how my firm approaches the prototyping process is a major distinction for us and is what most of our prospects are hungry for.
     
    So I’m definitely with you in engaging the client in holistic thinking no matter what the decision is–whether it’s a logic workflow within the functionality of the website, or the color of a text headline.
     
    I’m enjoying this conversation!

  8. Chris,
     
    Thanks for the reply. I really appreciate you taking the time to respond to my remarks, and I promise not to distract you much longer, but I did want to comment just once more, in clarification.
     
    I tend to agree with most of what you’ve just said above: that your prototype (or some wireframes in general, in my opinion) act in many ways like blueprints, and are a guide for developers to achieve the proper, intended build.  
     
    The main point I was trying to make has to do with the timing of this prototype in the process. You seem to be making the case that the process should begin with the creation of these grey layouts/prototypes (even if they take much time and many iterations to finalize). This forces people to make judgements about the final design/layout/content, without actually having experienced anything.
     
    I believe that this sort of thinking perpetuates the notion of the web design discipline as merely a technical one, relying solely on silly conventions or hackneyed formulae (higher up the page means better, right?) 
     
    This can also often hold us back from creating something novel. Most good designers can take these grey screens and see past such prescribed limitations/layouts (be they intended or not), and may often disregard these wireframe-type layouts to start fresh (but if these layouts are changeable, as you say, then what’s the point of laying them out in the prototype? *He asks, rhetorically*). That can be dangerous, risking upsetting a client who may be expecting a certain layout that they think they’ve already decided upon, for example. And the reality is, many designers won’t see much past them (not that they can’t, but possibly because of this perceived fear of upsetting the client, or because it’s easier, or even just because we’re reinforcing analogies like “the blueprint” one (which of course is a document of plans to be followed exactly)).
     
    A better solution, in my opinion, is to get the client to focus from the start on what it is the page/site is trying to do or communicate. Work with them to rank these areas of content in a non-visual way, which will force them to make good, often difficult, priority decisions, and avoid the “but everything is the most important!” scenario.
     
    Then it’s the design team’s job (which, yes, should include developers) to take all of the up-front thinking and do what they do best—what they’re trained to do. Design the whole experience. And then present and critique and revise with client and developer, etc.
     
    I know wireframes/grey screens that precede “design” are the norm right now, but our discipline is so young, and we’re all still shaping it. I, for one, would like to put design first.

  9. Neal,
     
    You’ve raised a bunch of very good points. Let me first start with the false analogy issue: Had I said that prototypes and blueprints function in exactly the same way within their specific design frameworks, you’d be right in calling me out on the analogy. But that’s not really the point I was making. What I wrote was that blueprints use a unified visual language to describe an aspect of a building just as prototypes use a unified visual language to describe an aspect of websites. My point in this analogy was not to compare the blueprint and the prototype exactly, but to make a general comparison in order to highlight the particular, focused role of the prototype in a much larger process. I really just wanted to introduce the notion that prototypes speak a particular kind of language in order to represent the intent of a project so that it can be interpreted by designers and developers. (By the way, my diagram was showing blueprints to finished houses vs. prototypes to finished websites, not, as you said, blueprints to elevation rendering. Small point, but needed to be said.)
     
    On that note–the role of the prototype–let me address one of your other points: I couldn’t agree with you more about the expansive nature of design and am not at all trying to limit that by recommending prototyping. This is where, I think, you might be getting the wrong idea about how prototyping works. If the prototype was created in one, concentrated pass in exclusion of the client (not to mention other key team members, like designers, developers, etc.) then your concern would be warranted, as would your idea that I’m directly and fully comparing prototypes to blueprints. But prototypes are the result of weeks (if not months) of iterative, collaborative design-oriented thinking. They start very abstract and solidify over time, in large part due to the valuable input of the team and client alike. Once they’re done, they are more directly comparable to the blueprint in that they serve as the “source of truth,” or spec for the developer to follow. Just as they describe what the developer should do next, they also describe what the entire team has done for weeks prior. Not to belabor the point, but prototypes are a process just as much as they are a document.
     
    Finally, I can understand your discomfort with the neutral aesthetic of the prototype. But I’m going to stand by that one. Having done this for years, and having not experienced anything but positive reactions to the “soft” sequestering of information architecture from the visual design process–in other words, our many clients from a wide array of backgrounds have all found this to be helpful–I can’t say that I have good reason to recommend otherwise. That said, you’re right that a website cannot be fully experienced without the visual side of things. The prototype is only a piece of the experience, but it’s a focused one: the information alone, first. We could certainly quibble about this at length; I understand and respect your objections. In fact, the agile web development process, which has its place for sure, is more along the lines of what I think you’re making a case for. It’s not the process we follow, but many talented and productive web shops do.
     
    Anyway, I sincerely appreciate your deep reading of the article and your thoughts in response. These are the kinds of dialogues I was hoping to have through contributing to imPrint! Thanks for reading,
     
    Chris

  10. Interesting article on a topic that I, and clearly many web designers, wrestle with. However, I feel you’ve missed the mark in promoting a false analogy here—that of the Architect and her Blueprints.
     
    This analogy has come up before in trying to rationalize wireframes or prototypes, but there’s a problem with how you’ve described the process here: blueprints should (and do!) come after the initial concept and design is presented to the client—usually in the form of of an elevation sketch, architectural rendering, or scale models (real or digital).
     
    Design is founded on the need to solve certain problems, based on various needs of the client and limitations of technology or medium. We all know this, of course. But this is where design should start, thinking about these bigger picture problems and solutions in an abstract way, rather than from an already decided upon (even if slightly flexible) layout and order of things.
     
    When Peter Eisenman or Frank Gehry (or any architect, for that matter) present new concepts to clients, do you think they first unroll blueprints of the building, get the clients to decide upon placement of rooms and other elements, and only then go back to the studio and “design” the building? Of course not.
     
    Architectural presentations start with visual renderings. That is where the experience lives. Blueprints come later, and in fact, are not created to be experienced by the client (though certainly some interact with them)—they exist for the construction team. They tell the builders how to achieve the vision already decided upon by the architect and client. This is, it seems, what you use your prototypes for: your developers (builders). This is great, and is necessary at a later stage in the design process to achieve a solid build, for sure. It just shouldn’t serve as a design starting point for the client.
     
    So, the architectural diagrams in your article are backwards (your arrow from blueprint to elevation photo). The elevation rendering or model comes first, then the “aesthetically neutral” blueprints are created later to satisfy the experience.
     
    Seeing things without “aesthetic hang-ups” is exactly what we do not want clients to experience and make decisions based upon, as that’s not how any end-user will interact with a site. Usability and experience is a result of the wholeness of a design (hierarchy, visual colour, texture, sequence, semantics, etc.), not just from the mere placement of blocks of content on a page. Any attempt to remove visual design from a website and judge its usability or experience is simply insufficient.
     
    Phenomenologically, you can’t accurately experience a website from your grey prototype, in a vacuum that excludes the context of everything mentioned above.
     
    This sort of thinking would be suspect in architecture (or in print design) and I feel it’s one of the things holding our web design community back from attaining the status and respect of other designers and creators.

  11. Paul: I agree. Prototyping is a non-negotiable for our client engagements, but I realize that for a designer or firm just starting out with it as a practice, it may not be possible to take such a hard line. Good luck!
    Devin: We don’t use Fireworks; we use a proprietary prototyping tool that is based, in part, off of our content management system (CMS). There are many other tools, though, that you could use to build prototypes. One I recommend often is ProtoShare (http://www.protoshare.com). So, yes, whatever works is certainly better than not prototyping at all.
    Thanks for your comments!

  12. Pingback: Article: How to Think About Website Prototypes « Graphic Design Cluster

  13. Christopher these are beautiful!
    Technical question: Is Fireworks used to make the prototypes given that it is the “preferred” software for such work? Or does the team use whatever works? 

  14. I think i would be great when you can have this ‘prototype-fase’ with each and every client! I really love that it focusses on the essence of the website: usability.
    In reality, in most cases there isn’t enought time (money)…