With all the great prototyping tools that are around these days, some people are heralding (or bemoaning?) the demise of the humble wireframe. But if we play to their strengths, I think they can do what fancy prototypes can’t.
My understanding of wireframes is that they are conceptual illustrations displaying the visual structure, priority and arrangement of all the elements needed for each page type in a website or other online product. They also display differences in appearance and behaviour for each state needed (logged in or not, an administrator’s view as opposed to a manager’s view, and so on).
Standard user experience design practice is to produce wireframes before the final visual design for many reasons, not the least being you can solve all (OK, most) interaction design issues at this ‘bare bones’ level before committing to the visual design. And changes to visual design are more fiddly and expensive than to wireframes.
Great for us…not so great for clients
So wireframes suit our processes. But let’s face it: clients are typically underwhelmed by wireframes, and would much rather see the finished result first, with the visual design implemented. Wireframes are typically plain, boxy, and – well – ho-hum. They don’t have the pizzazz that clients are eagerly waiting for. And we haven’t even mentioned clickable prototypes yet, which would be more preferable for clients still.
If we try to dress them up, we run the risk of confusing clients, making them think that they are looking at the visual design, rather than the conceptual design.
The strengths of wireframes
There are several ways out there to approach this dilemma, and most of them involve trying to leap-frog the static wireframe stage. But I think there’s merit in not only retaining this as a vital step in the design process, but levering off the strengths that wireframes actually provide:
- Wireframes are great for encourage ideas-capture – firstly, wireframes are fast; you can pump out a lot of wireframes illustrating your ideas and solutions quickly. This means you can communicate ideas to clients early and often. Internally, it also means you can bin the ideas that don’t work and bullet-proof the ideas that do work efficiently.
- Wireframes encourage collaboration – wireframes are conceptual, so they should actually encourage client collaboration and a sense of co-ownership in the design process. Presenting clients with something too polished can run the risk of leaving them feeling left out of what is probably the ‘fun part’ of their job in engaging with designers.
One solution: treat ‘em rough
The key, then, is to keep wireframes quick, sketchy and informal. I’m a big fan of Dan Roam’s book The back of the napkin, and one of the key take-aways for me is the power of a simple sketch to communicate a lot of information.
So for wireframes, here are a few ideas that have helped me in my projects:
- Sketch and scan hand-drawn wireframes and show to client project teams as early as possible, to discuss solutions and ideas with them
- Sketch up figures representing different personas next to wireframe sketches, showing the link(s) between persona tasks and scenarios, and how that particular wireframe design achieves the tasks
- Try to have a whiteboard handy when discussing interaction design ideas with clients, so that you can instantly sketch up what you’re talking about (and try not to stage it… or if you do make it look spontaneous, not contrived)
- If you’ve been brainstorming using whiteboards and sketches, take photos as you go, and share these photos with clients (in emails, reports, etc) if it helps to communicate your design thinking
A couple of examples
Here are two of the rough wireframes I did for a website about information and action to live more sustainably. The purpose of the sketched set of wireframes was really to quickly ensure that we and the client meant the same thing when we talked about ‘hero areas’, page zoning, and so on. Turns out they really liked the sketched approach.
Sketched example of the home page
Sketched example of a content page
I could expand on those points, but I’ll leave that for another time.