Wireframes are so widely misunderstood, so much so that i wander whether we should just stop doing wireframes altogether – I fear that may be beginning to loath them.
By their very basic nature wireframes are so ubiquitous that I think that they have started to be misinterpreted in their meaning and intention. At one of my previous organisation we always set a context when inviting feedback from a client, we used to say that they are only there to show the priority of elements on the page; the fact that we do go into a lot of detail is synonymous with the nature of the agency to try to achieve much more in a relatively short period of time.
Even as a prototype, (whether omnigraffle, Axure, visio or scamps on a series of bits of paper) wwireframes are meant to be useful in determining how the user interacts with and migrates through the screens during their journey. They outline the hierarchy, priority and juxtaposition of content and elements on a page. In Axure, we used these to create our clickable prototypes which extends the former to include and demonstrate user behaviours. I think too that we used these to try to document the usability of the system too.
So what’s the problem?
They are typically open to interpretation (which is a good thing from a creative perspective) but without an explanation, without a context, they are typically read in a number of different ways. Passing on wireframes without this explanation just makes the UX designer’s job plainly and frustratingly difficult.
Once that perception has been cemented in the mindset of the reviewer, it is sometimes impossible to bring the individual back to a point where you can progress together in the journey because the client is already telling you what they want to change. Wireframes and prototypes then become slave to the visual descriptions and directions from the client rather than demonstrating them in the context of finding answers to the questions raised.
Conversely there are others who believe that they are too prescriptive and can add unnecessary wastage to a project. Too much is defined up front and it can lead to an approach which encourages us to pass it on and focus on the next job (something which is much more easily achieved than one might think). If this is the case then it is very difficult to break the vicious cycle within an expanding team. Even though this approach certainly has its uses in small teams where there is a growing necessity to demonstrate that projects are moving forward in the right direction at pace.
So if they contain too much, then how much do we wireframe or prototype to be useful?This question depends very much on the intended audience, but the answer is always just enough.
I’ve been asked to do some mad things in the name of wireframes – they include wireframing the entire site so that the client can sign off on everything. A client describing their new project while expecting us to just dive into wireframes without understanding who or what we were doing – I’ve even had a response of “I just need you to get inside my head and show me what I mean”…
So should wireframes and prototypes be left out on an ice flow to fade away into obscurity? For now, in the absence of anything that communicates as much in as short a time, we have no other option but to sustain their life, perhaps even if on life support.
But what I can do is encourage others not to expect too many in future and only then when it is necessary to convey meaning that can’t be captured any other way. They are still very useful to have around; we just need to be careful that we don’t drown in them.
As a footnote, perhaps their revival depends very much on cross-collaboration where they become more a record of what was discussed or when some of the more current industry standard or more sophisticated tools can produce useful HTML and CSS – not the mess that prevents the UI team from restarting the development cycle. So in short, I think it is how we evolve as teams that will determine the conversations that will guarantee the success of wireframes and prototypes in future.
Frazer Cooper 