Wireframes: At once a singular composition and a collaborative expression, communicating the vision of both an individual and a team. Their visual language must be detailed enough to be widely interpretable, yet particular to different audiences. As a result, wireframes can be stacked with an enormous amount of detail. Are we becoming victims of information pollution in our own wireframes?
Jakob Nielsen recently warned us about information pollution, commenting “excessive word count and worthless details are making it harder for people to extract useful information. The more you say, the more people tune out your message.” This resonated with me (perhaps not in the way Nielsen intended) because of an evolution I’ve seen in my own wireframes.
There seems to be a parallel relationship between level of detail and accepted-ness. As information architecture grows to be a defined step in my company’s process, my wireframes have grown more detailed; more departments must participate in and comment on them.
Once a calculated expression of gray boxes and greeked text, my wireframe has grown heavy with detail, chaotic even, sometimes communicating the desires and requirements of an entire project team. Each layer of detail (and there are many) is intended for a different audience: partial business rules for technologists; a page weight guideline for developers; an idea about a visual system for designers; a justification about “Phase One” features versus “Future Phase” features for stakeholders; even notes to myself sometimes creep into the sidebar.
How did this evolution come to be? And, more importantly, how can I stop it?
In Understanding Comics, Scott McCloud shows how a drawing of an ordinary smiley face can be a more effective representation of a man’s face than a photograph. Abstracting out a smiley face as such allows audiences to focus on the intended detail. Audiences are free to interpret the drawing, projecting their own past experience and meaning upon it. When faced with a photograph of Robert DeNiro’s face instead, the audience immediately makes judgments and assumptions simply because they recognize him.
My wireframes, unfortunately, have become almost photographic.
I’ve realized that it may be impossible to not see the semblance of a design in a wireframe with a lot of detail. A gray bar down the left side may show information grouping to the designer, but is immediately recognized as left navigation to the business owner. Levels of detail intended for audiences of every type are polluting my wireframes, forcing my audience to project their prior knowledge and experience upon them. This, I’ve found, leaves little room for innovation.
As information communicators, we must be conscious of how our information receivers are interpreting wireframes. As information managers, we must be conscious of how we position and take inventory over the data. As information designers, we have to regain control over the content included in our documents. Here are a few ways I now keep the clutter down:
- Amplify through simplification.1
Ensure that information is presented clearly and plainly. Use wireframes without color, without icons, and without layout recommendations. If there is a danger the audience will be distracted by multiple elements on a page, create separate pages, each illustrating a different point. - Cut out unnecessary details.
Is your annotation covered in another document or on another page? Are you communicating something that is outside your area of expertise? Ensure that every item is critical to the wireframe at hand. If the navigation is the same on every page, for example, there is no need to repeat it. - Annotate thoroughly but relevantly.
Does your wireframe have to stand on its own? Will you be there to present it? The details you include should match how and where the audience will digest it. If you are presenting to technologists, you might not include all the content strategy recommendations.
By stripping out these extras, I’ve been able to focus on the points I need to make to each audience. In meetings, I can focus on getting across relevant information. Over email, I can control interpretation by using general visual language. Everyone, including me, can remain focused on the page-level interface design itself. I’ve found that this not only improves my wireframe communication, but also improves communication of subsequent deliverables.
The most targeted information—not the most information—allows for an understanding of wireframes that is precise and accurate.
Liz is an information architect in New York City and teaches design history at The New School University. Liz has a B.A. in English from Penn State University and an M.A. in Professional Writing from Carnegie Mellon.
Her personal site can be found at bobulate.com.
Liz –
Wonderful to see your thoughts on this topic. In large degree, I couldn’t agree with you more – the pitfalls of over producing or over weighting wireframes are big. And the very usefulness of the document, and sometimes the smoothness of a project, are at stake.
However, I would challenge you on the idea that the answer is to make them simpler or to strip out extras. Or more specifically, I say get as detailed as possible, but develop the documents to be more customizable and readily available to appeal to different specific audiences. It seems that you are advocating a zero-sum game for wireframes, strip out some info to save other info – so no one piece of information can be presented without first losing another. I’d say lets turn that on its head and look to add value in a positive non-zero-sum scenario. And here goes…
I’ve noticed the same evolutions in my career as an IA that you note- the role of the wireframes and site map documentation is expanding as teams get more insight and experience in to how to use them effectively. So indeed, instead of their being 1 audience for wireframes, there are often 4 or 5 or 10. My response has been to deliver the same baseline document to each audience type, but comment only the parts that are relevant to that individual reader.
This is clearly analogous to classic Architects. To build an apartment building, an architect doesn’t draft a single set of documents – that would be madness. Instead, using the same basic features of the building as a foundation, an architect creates separates blueprint schematics for the electrical contractors, the carpenters, the plumbers, the landscapers, the fire warden, and probably Barney Rubble if he were to want one. Each set of documents have common elements but are specialized to the reader. In the larger strategic context, these individual (and tactically minded) specialized documents each represent a piece of the whole. And the whole can not be completed without each doc. Hence the strategy is to specialize such that each layer of document is independent for the specific audience but dependant on the others for the big, whole picture. Now that is some positive non-zero-sum goodness right there!
Bringing it back home – if an IA or architect were to then layer these documents one on top of the other, then all the areas of need would be addressed, but the metaphorical three dimensionality of the multiple layers allows for quicker dissection and consumption of the specific information each audience member requires.
Visio has some layering features in it (granted they could be seriously enhanced) that allows for sets of notations to be created and turned on and off on a page level with a single click. In this way I can create a baseline wireframe deck that has each actual wireframe/page as its foundation, but then I can turn on different sets of notes for each page in order to appeal to different readers.
I’d love to hear anyone’s thoughts on how this layering or 3-D metaphor can be turned into a more powerful document creation software.
Other than that, I trust you will find more treats than tricks this Halloween – and I hope to talk to you soon.
.christopher daly
Christopher, I fear that creating audience specific annotations may be a bit presumptious on our part. Readers within a certain audience may have concerns outside of their group. For example, I have some clients that ask technical questions or designers that have a marketing concerns. If annotations were written solely on an audience basis than they’d miss these in their drafts.
Additionally, I worry that creating different views of essentially the same (wireframe) document could lead to a different kind of information pollution. I can easily see a reader get the wrong audience version of the document or a project manager or even IA get confused between varying copies.
In regards to Liz and the article in general:
A co-worker and I were talking about information pollution in annotations recently and yes it can be a problem. There’s little need to label obvious functions (don’t tell me in an annotation that the “home” link takes me to the index page). Unfortunately, in my experience it’s a rarity to see ENOUGH annotation let alone TOO MUCH.
Furthermore, while I agree specifically that near “photographic” wireframes can impede “innovation” in visual design I find that tends to be the case when only dealing with junior level designers. Visual designers with more cycles clearly understand that wireframes are a jumping off point. Clients rarely have difficulty with this concept as well — esp. when they see the more “photographic” visual boards.
I also think it’s far more difficult to convey information relationships “without layout recommendations” than she implies. If the samples of work on her site (I *adore* the sensibility of it by the way) are any indication of her “amplification through simplification” concept then I think she does as well. Again, I think it’s only with the most inexperienced of visual designers and with the most dogmatic clients that it’s a problem for wireframes to function as a “first crack” at layout. My concern otherwise is that wireframes begin to turn less into “page schematics” and more into module wireframes or object models in general thus sundering any attempt at depicting information relationships.
Generally speaking, the push/pull between abstraction/photographic (I’d prefer the term concrete or plastic but we’re not all coming from art historical backgrounds) is something I’ve noticed as well over the years as wireframe documents developed their own visual idiom. Personally, I cannot help but feel, at times, that the level of abstraction in wireframes hurts us more than helps.
Chris, the layering idea you suggest is much like the approach I use when reviewing functional specification documents with different teams. Depending on the audience, while reviewing, I’ll take teams through only specific pages or sections. This targeted approach avoids taking an attentive audience through unnecessary detail (rendering them inattentive eventually). The layered visio approach would serve this same purpose. To that end, what we’re discussing seems to be less like decreasing the amount of information, but rather controlling the view of it.
At the same time, I agree with Daniel, there is potential for uncontainable version control issues, and questions about which version/view of the wireframes become the “authoritative source.” Perhaps only in situations where you know the whereabouts of your documents at all times (thus maintaining control over viewership) could you manage the possibility of versioning snafus. It seems that working in-house this kind of control may be easier than it is when one is a consultant, but still not completely predictable.
– Liz
Perception studies show that simplification does not always create clarity (contrary to modernist beliefs). However, accumulation of objects on a page creates much visual noise, since the space between the objects also creates visual entities.
I personally feel that if you can’t make a scheme that will make sense to most people, the end product won’t, either
A lot can be done to reduce visual clutter. For one, our wireframes could stand some less wires and frames. Good use of negative space always helps. I always try to think, “Do I absolutely need that line/contour?” if the answer is yes, then the next one is: “Does it need to be so thick/dark?”
In my opinion what’s important is not reducing the number of elements, colors, intensity, but putting them there only if they play a role in conveying meaning.
As for the creation of different documents for different audiences, sometimes the backgrounds of the audiences and the level and aspects of a project they need to know are so different that if you try to combine them you get a ‘jack of all trades, master of none’ kind of document. That does not mean that you don’t communicate technical ideas to the client or marketing ideas to the designer. Just like in a web site, try thinking of different ‘user paths’, based on your audience’s behavior.
I agree that wireframes can be a tricky deliverable. I’ve seen many clients mix the purpose of wireframes and visual design…despite our in-person explanations to the contrary…and requesting essentially visual changes to wireframes.
For about a year now, my company has been switching up the order of wireframes and visual design. We’ve seen marked improvements both in our client’s understanding/acceptance of wireframes and our design team’s feeling that they are encouraged to innovate on the wireframe’s layout.
First, we produce 2-3 “internal wireframes” to get a general feel for navigation, hierarchy and amount of content. Then our visual designers visual explore (prior to the client seeing the 2-3 wireframes) 2-3 look and feel options. We then present both the wireframes and visual explorations to the client together, which allows the client to see how wireframes evolve into the end product.
From that point on, both the client and team seem to put a bit less pressure on the wireframes as an end-all be-all deliverable.
This comment is a bit off topic, actually its really off topic.
I have a question of all people in job roles that involve wireframing for the web
Boxesandarrows discussion on the definition of “the web”:
http://www.boxesandarrows.com/archives/expanding_the_approaches_to_user_experience.php?page=discuss
Question:
Every wireframe I have seen, have all been designed on A4 landscape?
I personally prefer creating them on A4 portrait, it more accurately presents the 800px width screen and also gives a clearer idea of what content (when position denotes priority) falls below the fold ie. outside of an 800x600px screen.
I must confess I am pretty much a self taught ID, with guidance from colleagues with no time, so if there is error in portrait wireframes could someone let me know and why?