Journal

Broken wireframes

Konigi wrote recently in What’s broken about wireframes and how can we fix them about the limitations of wireframing that will have struck a chord with many user experience designers, myself included. It makes the point that wireframes can be limited in communicating design, lack flexibility and take too long to create and iterate. But, to my mind, it’s even worse than that…

Deliverables can be dangerous

In my experience, wireframes deliver most when they are a working part of a process, rather than as a formal delivery. It’s when they stop being principally a means for collaboratively developing ideas — both within your creative team, and with the client — that the tendency for wireframes to be ‘designed for sign off’ increases. By this, I mean, that wireframes can become intentionally bland and uncontroversial in order to enable the project to keep moving. To this extent, they remind me of 37Signals’ long-standing opposition to functional specifications:

‘Functional specs are about appeasement. They’re about making everyone feel involved and happy which, while warm and fuzzy, isn’t all that helpful. They’re never about making tough choices and exposing costs, things that need to happen to build a great app.’
Getting Real by 37Signals

Having then reached this point of sign-off, it’s not uncommon for wireframes to then become a forgotten part of the design process, reflective of merely a point in the process, rather than current shared thinking as the project progresses and, inevitably and naturally, evolves.

‘This is not a design’

For years now, every presentation I’ve done of wireframes has been preceded by a slide containing the message above. But it isn’t true. It’s difficult not to apply just a little design thinking — even if it’s just making your wireframe orderly and with a decent typographical rythym — because we and our clients are naturally drawn to such things and find them pleasing. And easier to sign-off.

But it’s dangerous ground — getting buy-in and sign-up can be dependent on a level of design finish that contradicts their purpose, and can begin to set unintended expectations. As user experience designers we have to be extremely careful here — I personally never stray from a single ubiquitous font-face, and no colour, except for indicating hyperlinks in ‘default blue’. Over-specified wireframes limit design and developer involvement and engagement, where it can feel like the thinking has been done.

In my own practice, I’m finding myself increasingly using a combination of sketching with no more than a pen and paper and my own variation of Jason Santa Maria’s Grey Box Method to create as much separation as possible between the information design and visual design to try and avoid boxing designers in, and leaving little but the colouring in to do.

Who are we designing for here?

Wireframes have more than one audience — client, designer, developer — with very different needs and levels of experience. So, it’s not unreasonable to conclude that these different audience’s needs are going to need varying outputs.

I’m particularly interested in the approach that Scott Thomas described in his extraordinary work with the Obama comapaign: separating ‘functional’ and ‘strategic’ wireframes to show how zoning content targeted campaigning need:

But in another wireframe he hit an interesting spot, showing boxes that contained the following words: ‘persuade’, ‘localize’, ‘represent’, ‘educate’ and ‘activate’. What he did in that wireframe is break the page up in different messages and seeing the website as a story. This is a really good approach, showing the strategy of the page.
EuroIA 09 report: day 1 by Johnny Holland

This connection between design research and information design: identifying the key themes and communicating them through wireframes is really critical for me, helping the client see the connection between strategy and design, as well as understanding how to read and interpret the wireframes.

Where do we go next?

Wireframing has to be both a tool for idea generation and for communicating design. However these are then produced and whatever the tool used to do do, the key is what you do next.

Whether you’re working with HTML prototypes, Omnigraffle, Axure or any of the other bewildering number of apps out there, it’s the quality of your communication that matters most: whether that be in your annotation; your ability to walk a client through the wireframe’s purpose and function; your ability to provide your clients with the tools they need to sell on your ideas internally; and your skill in involving others in your creative team and aiding the design and build process.

Good wireframes, it turns out, are produced by good communicators.