Website Prototyping, part 2: The Language of Prototyping

Editor’s note: This is the second of a 3-part series by HOW Books author and HOW Interactive Design Conference speaker Christopher Butler on prototyping for web design. All 3 articles are excerpted from his book, The Strategic Web Designer. Check out the previous article:

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 …


See more by Christopher Butler, including books and design tutorials, at MyDesignShop.com.


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. But 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?

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.

Want to learn more about how to prototype a website? Watch for the next article in this series:

  • The Structure of Prototyping

More Resources for Website Designers

COMMENT