Wireframing is a fairly ubiquitous tool used as part of the UX process when building sites, apps and games – anything you would interact with through a screen. Generally used to convey what requirements and features are on each page or screen, and to communicate a rough understanding of layout, grouping and hierarchy, wireframing is a great tool for UX practitioners.
This post is not about whether wireframes are needed or not – sketching out a project in one form or another is never a bad thing even if your canvas of choice is the back of a fag packet … and semantics aside, I see ‘sketching’ as wireframing too; sketching out pages or features is simply wireframing in a very low fidelity manner. This post is my thoughts on why low fidelity wireframing can be a much more useful process than high fidelity wireframing.
I will try to outline my issues with high fidelity wireframes below:
They are costly to produce
Firstly they are time consuming (and therefore costly) to produce – time better spent prototyping and refining features rather than specifying and documenting them with detailed annotations and diagrams.
They can become scope
With full-on bells and whistles wireframing there is a risk that a wireframe document becomes a project scope – other documents should be fulfilling this task, using stories and scenarios is a sensible approach to defining functionality and scope and one that developers can produce and work to.
They can be intimidating
Very detailed annotated wireframes are often cumbersome, can be intimidating to those unused to working with wireframes, and are hard to decipher. They have a very ‘final’ feel to them when they need to be open to amendment and feel ‘live’ – wireframes should be ripped up regularly – the first iteration of your wireframes will never solve every problem, and will always highlight issues that will need fixing.
They are too prescriptive
Probably the most common issue most would have experience with is when wireframes are too ‘designed’. This leads to issues with your client having to separate Information Architecture from design. Again, hard to do if you are not used to working with these kind of documents. I have had very sensible UXDs tell me this ain’t so, clients know the difference. Well, sadly my own experience contradicts this – having once been parachuted halfway through the ‘discovery’ process of a site build, when visual designs were finally presented I had to explain why I wasn’t using the button styles as defined on the wireframes …
… and this leads me to another problem with high fidelity wireframes – the situation where non designers are designing. By choosing that option of beveled corner, that line thickness, design decisions are being made that will be hard to unpick later when a visual designer gets to start the design process. “… but I liked those buttons you had in the previous designs …”
High fidelity wireframes can also be very prescriptive for a designer, and take away the value a good visual designer brings – even for grouping and layout wireframes should not be too prescriptive and need to allow for interpretation – wireframes cannot show how typography, colour, tone, contrast and texture can can all impact upon the hierarchy of information on a page.
The UX community is its own worst enemy with this issue. The amount of high fidelity tools and GUI kits available to create prototypes, diagrams and wireframes is a little scary. Perfect for rapid prototyping but not so good when used for static wireframes.
I understand the temptation to make a wireframe look pretty, resist it. If you can’t resist it, then you’re probably a frustrated graphic designer rather than a UX designer. If you’re worrying how a client will get excited about a load of grey boxes, how you’re going to sell an idea based on a sketched wireframe – well, if you’re asking those kind of questions you just don’t get what wireframing is. You’re a salesman or marketeer and you need other tools.
Your clients need to be able to divorce features and layout from aesthetics – functionality needs to be understood, tested and refined without the influence of style. Coke, for example, are instantly identifiable due to their strong red colourway even though they are currently all about personalisation (buy one with your name on it!). These values inform your concept, your idea. There is no need to to colour your wireframes bright red.
So what makes low fidelity wireframes or sketching any better?
Low fidelity wireframes encourages collaboration
Anyone can draw. The simple physicality of paper and pens lends itself to a more open discussion. Rather than one sole UXD in front a computer screen, diagramming away in Omnigraffle or Axure, UXDs, UI designers, developers – all can have input when sketching around a table. The wireframe does not become a document with one author, to be checked and approved by others, but a collaborative piece of work which can have input from all relevant areas of your business.
Sketching and producing low fidelity wireframes is a fast exercise: you fail sooner, which is a very good thing – problems can be identified and solved much quicker. Deal with fail as soon as you can. Speed also means several layouts can quickly be reviewed, refined or discarded. Time less spent on wireframing means more time and budget can be spent prototyping, a much more valuable exercise than creating detailed static wireframes.
Low fidelity wireframes look just that – lo-fi. Even more so if sketched onto paper. This communicates that the wireframes really are just sketches and not design. By avoiding ‘design’ discussion can focus on features, hierarchy and layout rather than whether your button edges are rounded or not.
Gets your client involved
Around a table, participating in the production of your low fidelity sketches, can sit your client. And this is possibly the greatest advantage of low fidelity wireframes – you can involve client stakeholders from the start – and not in a political exercise, giving client involvement a bit of lip service, but as a way to gather vital opinions, thoughts and insight. Opinions that might pop up to rock the boat unless you can prise them out of your client and deal with them at the earliest possible stage.
So, to sum up – I am definitely a low fidelity fan, but I can see the case for more high fidelity wireframing; for when complex functionality needs defining but is not reliant on visual design. Lists and search results, e-comm functionality and pages based around forms, all examples where more fidelity could be needed. Even in those cases, any high fidelity wireframing is logically an evolution of low fidelity wireframing or sketching. However you look at wireframing, the sooner you are prototyping, seeing and experiencing interactions on a screen, the better.
The best way of knowing if and what wireframes are applicable? Talk to your client. Find out their expectations, where they need help, where they don’t. Don’t have a standard process for every job or client, as not every job or client is the same. Easy!