Wireframing as a part of user experience definition: thoughts on fidelity

The wireframe is a ubiquitous tool in the UX armoury when building sites, apps and games. Wireframes are used to convey the requirements and features for each page or screen and to specify and communicate a rough understanding of layout, grouping and hierarchy.

The assumption that underpins this post is that wireframes are an integral part of the UX process. Sketching out a project in one form or another is always necessary. Indeed, I see ‘sketching’ as wireframing too – sketching out pages or features is ‘low-fidelity’ wireframing (as opposed to ‘high-fidelity’ wireframes commonly created using tools such as Visio or OmniGraffle).

I want to think about why low-fidelity wireframing can be a much more useful process than high-fidelity wireframing. My issues with high-fidelity wireframing are as follows:

They are costly to produce
High-fidelity wireframes are time consuming (and therefore costly) to produce – time that could be better spent prototyping and refining features rather than specifying and documenting them with detailed annotations and diagrams.

They can become scope
In producing high-fidelity wireframes you run the risk that a wireframe document becomes the project scope. Other documents should be fulfilling this task; for example 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, hard to decipher and therefore intimidating to those unused to working with them. They have a very ‘final’ feel to them when they need to be open to amendment and feel ‘live’. I believe that wireframes should be ripped up regularly – the first iteration of your wireframes will never solve every problem, and will always instead simply highlight issues that will need solving.

They are too prescriptive
The most common issue is that high-fidelity wireframes are too ‘designed’. This very often leads to misunderstandings or misapprehensions with regard to the separation of information architecture from creative execution. Understanding where one ends and one begins is very hard to do if you are not used to working with these kind high-fidelity documents.

Furthermore, high-fidelity wireframes often create a situation where designs are being established by people who are not designers. The choices made in producing the high-fidelity wireframe – by choosing that option of beveled corner or that line thickness –  are interpreted as design decisions. These are very hard to unpick later in the process when a visual designer gets to start the design process. This undermines the value a good visual designer. And its not just about lines and corners – the choices made in grouping and layout wireframes should not be too prescriptive and need to allow for interpretation by a visual designer. Wireframes cannot – and should not even try to – show how typography, colour, tone, contrast and texture can all impact upon the hierarchy of information on a page.

The UX community is its own worst enemy with this issue. There are numerous tools and kits available to enable the creation of high-fidelity wireframes. These are great for rapid prototyping but not so good when used for static wireframes.

So what makes low-fidelity wireframes or sketching any better?

Low-fidelity encourages collaboration
Anyone can draw. The simple physicality of paper and pens lends itself to a more open discussion. Rather than one sole user experience designer in front a computer screen, diagramming away in Omnigraffle or Axure, UXDs, UI designers, developers – everyone 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 competencies within the business making for richer, more relevant solutions.

Fail fast
Sketching and producing low fidelity wireframes is a fast: you fail sooner, which is a very good thing. Problems can be identified and solved quickly. Speed also means several layouts can quickly be reviewed, refined or discarded. Less time spent on wireframing means more time can be spent prototyping: a much more valuable exercise than creating detailed static wireframes.

Focus
Low fidelity wireframes look just that – lo-fi. This communicates that the wireframes really are just sketches and not design. By avoiding ‘design’, discussion can focus on features, hierarchy and layout instead of whether your button edges are rounded or not.

Gets your client involved
Clients can easily participate in the production of low fidelity wireframes. This is the greatest advantage of the low-fidelity approach – the active involvement of client stakeholders from the start, inputting high-value opinion, thought and insight.

Summary

I am definitely a low-fidelity fan. But we should not throw the baby out with the bathwater. There are use cases for high-fidelity wireframing, for when complex functionality needs defining but is not reliant on visual design. Getting to grips with complex lists and search results – both of particular importance within the scholarly space – are good examples of where more fidelity could be needed. the specification of e-commerce functionality and forms are other examples. Even in these cases, high-fidelity wireframing should be an evolution of those initial low-fidelity outputs and the sooner you are prototyping, seeing and experiencing interactions on a screen, the better.

So – what’s the best way to determine if you should go lo- or hi-fidelity? Talk to your client. Find out their expectations, where they need help – and where they don’t. Don’t have a set-in-stone process for every job or client, as not every job or client is the same.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>