Comments on The Devil's in the Wireframes

Lefke — Tue, 28 Aug 2007 00:43:27 GMT

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_appr…

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 800×600px 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?

Kathy Beymer — Tue, 28 Aug 2007 00:43:27 GMT

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.

Uri Ar — Tue, 28 Aug 2007 00:43:27 GMT

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.

Liz Danzico — Tue, 28 Aug 2007 00:43:26 GMT

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

Daniel Harvey — Tue, 28 Aug 2007 00:43:26 GMT

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 daly — Tue, 28 Aug 2007 00:43:26 GMT

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