Lemon Foundation

Imagine walking through the halls of a museum, not understanding hieroglyphics, any of the Persian languages, Aramaic, or even perhaps some of the Cyrillic languages. If you only knew how to speak English, the meaning of any of the above texts would be lost on you. Similarly, when it comes to delivering web projects, most of the things web professionals do is a foreign language to the average business person – where the average business person understands English (or for the purposes of this blog post, the language of their occupation).

However, when you walk into the ancient Roman or Greek halls of the museum, you’re struck by the visual cues that the ancients used to communicate. Yes, they did have their own language, but the frieze on the wall conveys the victory of the battle scene as clearly as the text beneath it.

Likewise, when it comes to delivering for the web, wireframes are the visual equivalent of the frieze on the wall. With wireframes, you get to create something that everyone can take visual cues from – so the structure and positioning of elements in a page are things that can be moved around and changed, instead of re-worded and abbreviated.  From a business perspective, it’s cheaper to get the visual process started with wireframes, than hiring a designer to create true design routes, too.

The big problem with most things technology is that in order to tie people into specific deliverables and timescales, suppliers are made to agree to and sign on specification documents that are generally long winded and overly complex. The problem itself stems from the different ways people interpret written text and descriptions – everyone draws their own conclusions and makes their own assumptions.

So, one of the ways you can get around this problem is to get into the joy of wireframing. There’s a simple satisfaction from delivering a set of wireframes to a client, and seeing them smile because they’re able to visually interpret things the same way you envisaged they would – there’s a congruency that you don’t often find in spec documents.

One of the tools we use, Axure (http://www.axure.com/), enables us to do exactly this. Because it generates an online prototype (which allows users to navigate between pages) that can be interacted with, and is so quick and easy to use, they get to interact with their project right from the beginning. As a result, feedback is immediate, and thus changes almost as immediate, which means that there is real, rapid iteration – mush more so than trying to get everyone to agree on a document. We’ve found that this is so useful that all of our medium to large sized projects have a wireframing / prototyping phase.

I’m not suggesting that you should get rid of the specification documents, as they have their place and serve their purpose, but I am suggesting that adding a wireframe process to any web project should be as natural as talking about the design - even more so since they both work hand in hand.

So, the next time you’re doing a web project, and you’re handed a 123 page spec document, and there’s no wireframes inside, you need to ask yourself if your interpretation of someone else’s specification writing is going to match up to your own expectations. Further to that, will the designer be thinking the same thing too?