Do High-Fidelity Wireframes Reduce Design Collaboration?

by on May 15, 2013

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, 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 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 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.

 

Comments

[…] what interaction design is or should be. I wrote a blog pos exploring the issues around this (Do High-Fidelity Wireframes Reduce Design Collaboration? |) , but TL/DR: clients may well like hi-fi, but unless you take steps to make sure this doesn't […]

I came here out of curiousity from the Axure Forum post about one-click image updating to see what was feeling your initial disregard for the feature.

I don’t disagree with anything you say here, and if I had a receptive stakeholder/paymaster, I’d even have him read it. Unfortunately, most of my experience has been with the worst situations you describe dictating the process of creation. I even moved around the world for better employment experiences, but found the same thing for less money. My current project that directed me to the Axure Forums looking for a quick update for +60 hifi screens is basically the methodology you described of polishing a turd because the boss is frustrated by how long it takes to redesign hifi designs on a daily basis when some new component or workflow suddenly needs to be added (instead of thorough mapping and a comprehensive wireframe stage).

In lieu of somehow changing stakeholders/paymasters into educated and considerate bosses, I’d say that the UX of UX software should be a priority for developers. I would be surprised if anyone in an interactive, programming, or design field hasn’t had at least one experience like I’m currently in, and that case should be used to create a personas and user stories.

Do you still have any thoughts on this? I’m very interested after reading this post.

If I understand correctly, you ‘re talking about features in prototyping tools (or at least in general UI creation software) that allow easy maintenance while keeping to high fidelity (so that you can avoid the otherwise inevitable slow-down as you get more visually sophisticated).

In principle, there’s nothing stopping that from happening. Tools like Justinmind and Axure have features designed to do just that (by separating content from the presentation, with reusable or polymorphic objects etc,)

The problem I think is usually always an “architectural” one specific to the type of project you are working on. UX design in the early stages is of its nature unpredictable. Are your problems big or small? Are the solutions you are thinking of simple or complex? How big is this project really? In many cases you simply don’t know until you get into the work. It’s very hard to imagine a tool that would scale from quick-and-dirty up to high-fidelity and all shades in-between. At some point you have to jump. And sometimes that jump can be very disruptive.

Unfortunately, it’s very hard to give examples of this issue without suitable background context. This makes discussions about UX tools very difficult because not everyone has the same perspective (BTW this is why I was careful to note some assumptions in my post above. Not because I think they are always true, but simply to frame the issues). Basically, if you spend most of your time doing corporate site re-designs, you are probably going to think Axure is pretty pointless. But if you are designing B2B product fulfilment systems, HR self-service, or other complex or heavily interactive things, and doing that iteratively, you might think it’s great.

I don’t know what the answer to this is though. I think the developers are conscious of the processes that UX designers go through, but just as designers are confused about many things in the design process, so are they.

Leave a Reply

Your email address will not be published.