Explaining User Research to those outside the ‘Agile bubble’
Rewind to January 2016 and the start of my time at Methods. My first client meeting ends and as we walk down the street, a colleague says to me ‘So… what’s user research then? I don’t really understand the point of it.’ I won’t embarrass the person by revealing their name but I hope he would agree that he’s (a little) more informed now.
It’s a more common question or comment than those of us in the Agile bubble might think. Most people have a vague idea about talking to customers or users via ‘market research’, ‘surveys’ and other labels; much of it hasn’t been a huge amount of use to them. They don’t really know what’s what. These people won’t be the energetic digital delivery manager or product owner with boundless enthusiasm on your first day on the project, but you will need their engagement and knowledge.
So, how do we explain what user research is and its reason for being, in plain English and fewer than 5,000 words? I guess it needs something pithy and accessible – we’re not speaking to a conference after all. Let’s maybe start with something about getting a wider understanding of the users of a service or organisation? Their environment, their perspective, their pain points, and above all, what they need to do. Explaining clearly and accessibly is so important in getting your message across to a non-research audience (and when upskilling). This is not just about understanding, it’s also getting people on your wavelength.
You will often find someone – that person – in an organisation. Maybe they’ve worked there for a long time, seen a lot of changes, probably more than their fair share of initiatives, seen new arrivals… and early departures. They know their users very well – they speak and write to them every day. And along comes you from out of nowhere, telling them they need to understand them better. Insert your own insult here.
Is their experience invalid or just plain wrong? Neither; in fact, it’s helpful to spend a good amount of time with that person to aid your understanding. But their view is nevertheless a perspective, and, crucially, an incomplete one. There may be much conversation with their users, but about what? And what not about? Maybe not a lot of questions (‘is this how you’d like to be doing this?’) or, more broadly, time to see the wood for the trees. It’s understandable – a lot of customer management involves more fire-fighting than time for (must I use it?) blue-sky thinking. So it’s important to underline that you’re building on what they’re doing; you’re complementing their knowledge, not replacing or dismissing it.
‘So, why are we doing this?’ What we do may of course build empathy, give us a better understanding of who it is at the end of all this, and all the lovely soft stuff on paper. But that’s not an end in itself – what will it actually give us? Perhaps it needs a slightly more hard-headed perspective.
Put simply, business objectives and user objectives should never be in conflict; if they are, something’s wrong.
Take one (real) example: a nameless organisation has huge amounts of avoidable contact; senior management complain there hasn’t been time to think outside the box as they’re constantly ‘on the hamster wheel’. Users say they’d much rather email or interact with the council online, but the former is mostly ignored and the latter, well… it would take several years of intense study to comprehend some of the online content or to transact with the few services that are actually there. So, what this does mean day-to-day? The phone’s off the hook, the F2F centres have an endless stream of queries that could have been answered or dealt with online, and all in all, there’s a ton of avoidable contact.
How do we crystallise this? By speaking to those who are at the sharp end. Users in front of the counter or at one end of the phone or computer, and those serving or speaking to them at the other. What the person at the back-end might not notice, the person at the front end certainly does. Getting this holistic understanding means we can begin to get to a place somewhere not 100 miles away from user-centred design. We can evidence the reasons for it; we can sell the benefits of doing it; we can see the results of having it.
This, of course, doesn’t stop once the needs and pain points have been identified; it’s just as important once you start building. Once more, this isn’t for its own sake. How much time – how much money – has been wasted because of ‘let’s see what our users think, now it’s finished’? Test and learn should fundamentally appeal to those who value caution and softly-softly. It decreases risk; it’s not taking one.
We then build wonderful services that meet all the principles of user-centred design, living happily ever after in a world where User Research is not a ‘nice to have’ but essential to digitising government. In theory, at least. But I would say that, wouldn’t I?
This article was originally published here.
