Right technique, wrong time

20 per cent of essential feedback is lost during user interviews

User interviews are a great way of gaining insights at the start of a design cycle.
User interviews help us understand how people think, their opinions, their attitudes and the way they are.

User interviews that take place in someone’s office, at their workplace, out on a client visit, in context, let us observe other information too.

I work on an application used by the construction industry. When we visit our users on site, it’s always cold, dusty and there’s alway an issue with the wifi.
It’s a world away from my office, where it’s warm, there’s beer taps in the kitchen (seriously) and me and most of my colleagues are tapped into wireless on at least 2 or 3 different devices.

But using interviews to test an actual design is not quite the right technique. Once you’ve taken in all of the information you can, through interviews and other methods, added this information into documents, onto sticky notes, into your design artefacts, and start designing your prototype, then you need to test the way people behave, not the way they think.

These two things are very different. I’ll give you an example:

If you interviewed me about my attitudes to exercise, and how important I think it is, and how much I prioritise it, I’m going to tell you “yes, yes, very important, very prioritised”.
If you come back and show me your prototype, I’m going to say “great, looks cool, nice colours, I don’t like the green though” and you’ll make those changes and release and you’d be fairly confident I’m going to be a user of your product.
Except if you had asked me to use a prototype of your application for a week, and tracked my behaviour with the prototype and how much I used it when I was exercising, or even how much I exercise full-stop, then you’re going to find out that I am a: a little bit not-honest with myself about how much I exercise, I don’t really use tracking tools when I do exercise and I didn’t want to hurt your feelings because you’ve worked hard and done a good job with your product. I’m nowhere near a target market for your app.

So I dunno about the article about asking people’s opinions about a new design, and whether online or offline testing is going to make much of a difference (except that people will be nicer to your face).


Are personas past their prime?

No, not if you’re designing for enterprise. They’re not. They’re really necessary because the people using your software are so different to you that you need personas in a way that people designing consumer products may never know.

But don’t treat them like glossy objet d’arts either

I agree with the warning about treating personas as glossy, canonised artefacts. Don’t do that. New insights about our users should be surfacing all the time, if you’re doing it right.

I am going to try the 2 1/2 D approach with my team. But I really, really I liked this bit: “you still need to have done the user research — you’re not going to brainstorm a persona out of thin air”.

I have actually participated in what I think of as creative writing exercises where personas were produced that were free of all facts. No facts to encumber them at all, those personas could be whatever we wanted them to be.

Don’t do that.