Do High-Fidelity Wireframes Reduce Design Collaboration?

There’s some debate about the utility of “high-fidelity wireframes” at work at the moment. It’s a reasonably common topic in the UX chattersphere too, so I thought I’d expand on it here.

Firstly, to avoid some potential misunderstandings – let’s make some assumptions about the domain we’re in:

1. There are two main roles on the UX team: visual designer and non-visual designer (the latter is my currently preferred internal term for what is often externally called “IA”, “UX” or “IxD”). These people (or they might be the same person) are designated as “designers” who do their work for others who are designated as “stakeholders” who approve the designers’ work before it goes out to real people (“customers”, “users” etc.) to use.

2. Any given artefact sits along a spectrum of fidelity, from paper sketches (or even simply verbal descriptions) at one end, to fully-styled front-ends on systems at or close to production quality at the other.

3. The best way of knowing if a design will work before you put it into production is to see a high-fidelity implementation of it. The higher the fidelity, the more confident you can be of the chances of its success.

4. In general (but not always) the higher the fidelity of the artefact, the more time and effort it takes to produce. Hi-fi artefacts thereby acquire a degree of inflexibility independent of whether their design is good or not. Hi-fi work is less likely to be abandoned compared to low-fi work because of the higher investment of time and effort.

I think a lot of the debate hinges on that last point, but more importantly, about what all this means for stakeholders’ participation in the design process itself. For brevity, I’m avoiding discussion of what this means for the relationship between visual and non-visual design disciplines, although that would also be something to consider.

Showing a visually high-fidelity wireframe (or similar prototype) to somebody who is not a designer is said to be better than presenting a more abstract concept such as greyscale screens or paper sketches. This is because the chances of them understanding the concept is higher. Some people, it is said, cannot understand things in abstract or low-fidelity form, and therefore cannot imagine what it might be like in final form. So if there is text, show actual text; if there is photography, show actual photography, if there are brand style guides, use them – and so on.  Going hi-fi before the build stage is therefore intended to address a common break-point in the process when designers who have been in the “primordial soup phase” of sketches and argument need to convince other stakeholders (probably also their paymasters) about what they have come up with. Low-fi wireframes or proofs of concept are fine, but only as a means of convincing the designer(s) themselves that they are on to a winner.

What I find most interesting about this argument is that it at least implies stakeholder exclusion. There is always the problem of too many cooks of course, but as a general rule, it would seem wise to get those who would approve your work to participate in its creation as early as possible. But if it is true that some or all of those stakeholders are going to be secretly incapable of abstract thinking, getting them involved early would seem to be a waste of time.

But delaying people’s participation until such time as you have been able to work up ideas to a high enough level of fidelity may also increase the risk of failure. This is the issue of invested effort noted in point 4 above. If a stakeholder points out a show-stopping problem with a hi-fi design, it may be less likely the designer will toss it out and start again, as they would a low-fi sketch. They may instead be tempted to polish a turd, as it were.

I find it hard to think my way out of this one. Either you accept that your client can understand a sketch and show them this for feedback, or you don’t. If you don’t, then call them in when you have something that looks near to complete, and your life will be easier. There seem to be risks associated with both ways of doing things. It’s hard to accept that people who aren’t designers can’t assess abstracted or low-fidelity expressions of a design solution. Yet I also find it tempting to keep disruptive participants out of the process. Perhaps a compromise is to involve such people at the start to establish business needs and project goals, then exclude them during the business of design before revealing a set of things that look almost final.