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.

Prototyping for Designers

Over the past month, I've been conducting interviews with many of our agency partners, clients, and colleagues to gather their feedback and deepen our understanding of the industry we serve. The things I've been hearing are both affirming and challenging, and I'm excited to begin to apply their insights to a variety of things—from how we work to the kinds of content we create. While I'm naturally cautious and unlikely to rush into things, I don't want to waste any time in acting upon feedback if there's something I can do differently right now. In fact, I'm starting with this article, which I've written in direct response to some particularly wonderful feedback I received from our friends at Callahan Creek in one of these interviews just a couple of weeks ago.

The gist of it was this: There is still come confusion about how designers should interpret prototypes, resulting in many unanswered questions up front. What, exactly, is the role of design in prototyping? Once a prototype is approved, which aspects of it should designers take literally and which are more flexible? As I listened to these questions, I realized that, despite having plenty of content about why we prototype and how the process works, we needed to answer them with material directly addressing the relationship between prototyping and design.

So, without further delay, here it is. Just a heads-up: this article is quite long and includes many visual examples that I hope will clarify the prototyping and design relationship. It doesn't need to be read in one sitting, but if you do want to tackle it all at once, you might want to top off your coffee and find a comfortable spot.

What You'll Learn

  • What a prototype is,
  • how prototypes communicate technical things without being overly technical,
  • how pages are structured in prototypes, and...
  • designers should interpret them,
  • and many other details that tend to be confusing to designers.

Ok, let's dig in...


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