Categories
Research UX

A few words about the Five Whys

Following this piece on FastCo Design about getting to the root of a problem, I thought I’d share a little experience of using the ‘Five Whys’ technique in the field, plus a few observations I’ve made on its use for user research for the web.

For those unfamiliar with it, the Five Whys involves posing an initial query (e.g. “Why is online booking so difficult on this site?”), asking participants for a top-level response, then gradually peeling back the layers of their insight by successively asking what makes their previous answer true. This is repeated until five answers have been offered, with five seen as the optimum number of levels.

Firstly, it is a great technique. Hours could be spent in discussion with users or stakeholders resulting in only a fraction of the information yield that this provides. When it flows well you will uncover hugely useful insights into underlying problems that could only come from those closest to the issues. When it doesn’t flow so well, you may be left with one of those activities that feels like a step too far, when you could really be pushing on with focusing on the salient issues. The common issues I have encountered using the technique in practice are:

The problem is obvious to participants – in this case, a problem can be so apparent that everyone nails the problem within just one or two steps. This can lead to some uncomfortable forced extrapolation as participants attempt to reword what is essentially the same point

The problem is obvious to you – as with all research, check your own preconceptions at the door, and listen. Your ideas about what the real issues might can blind you to the smaller details that might be hugely significant.

The problem is too abstract – what you are looking for may not easily be encapsulated in participants’ submissions. Visceral factors will not be readily dealt with in an environment where participants need to submit succinct, specific thoughts.

As with all user research, it’s best to simply persevere and work with the data as you find it. If the sample group is small enough, you’ll very quickly get a sense of obvious bias on the part of any participants. And needless to say if the group is large, anomalies will similarly stand out.

I have found it best not to reveal and discuss each participant’s answer before moving on to the next “why”. One of the major barriers to authenticity of results in research is that participants do not want to appear ‘stupid’ or caught lacking in front of other participants; revealing the line each participant is thinking too early is to invite groupthink into the discussions. Best instead to get all contributions in before proceeding with linking and clustering different responses.

Needless to say I wouldn’t base an entire workshop or test session around any one single activity, and the same applies here. Conclusions reached as a result of this activity should be cross-referenced against the results of other activities or discussions. But as a short and sweet method of quickly getting a group’s insight into problems – ususally as an opener – the Five Whys is a worthy addition to your research toolkit.

—–

The Five Whys technique has been credited separately to both Sakichi Toyoda and Taiichi Ohno of the Toyota Motor Corporation and is one of many excellent techniques collated in Dave Gray’s Gamestorming.

Categories
Community Design Process Research UX

Putting the spotlight on ‘delight’

Disclaimer: I tend to react adversely to industry buzzword memes.

A new word has been gradually creeping into the design industry lexicon. Designers should now, apparently, design for “delight” – and once again a word has been introduced without context into the forefront of design debate.

I’ve avoided ‘cool’ for most of my professional career. I don’t do ‘awesome’. I don’t trust it. I don’t strive for it. But I like ‘effective’. Effective I can work with.

The most rational, level-headed thoughts on this come from CX Partners’ Giles Colborne. The points Colborne makes illustrate that we don’t really know what we’re saying. It’s all too easy to drop these phrases into discourse, but it’s quite another to try and measure or define it. And yet invariably a section of the design community, certainly within web design, will regurgitate this type of commentary and broadcast it without questioning what it actually means.

I don’t disagree with the sentiment; I agree fully that ‘delight’ would be a.. um, delightful reaction for users of our work to have. But to impose this on an industry that strives for effective results appears to be imposing very shallow measures on a complex profession. If we’re going to propagate something meaningful, what about “design for success” – how’s that?

“Delight” is a meme and a millstone. It’s another way of saying that we should design something cool. But cool is not a commercial imperative, and it’s place in the process is undefinable. So, at what point should ‘delight’ appear? Until definitions and metrics emerge I will continue to hold such opinion at arm’s length.

There is no magic ingredient for a successfully designed product. There is only process and effort. As with cool, ‘delight’ will be a by-product of an effective outcome.

‘Delight’ happens, just as ‘cool’ happens, most often through rigorous attention to detail and a rock solid understanding of user requirements.