Being ready for things to go wrong is a key quality in user research. It doesn’t matter how careful your planning is; when you’re dealing with the public there is always scope for something to go awry.
The trick is being adaptable enough to make the most of a bad situation. Even in a crisis, there is still plenty to learn.
I’m a User Researcher on the Experience Design team at NHS Digital. Here’s how a recent hastily-organised user-research role-play session gave our team a new perspective on our project.
A 9.00AM no-show
The team working on the NHS National Data Opt Out programme faced just such a challenge when a participant couldn’t make their scheduled research session.
Team members and stakeholders were expecting to see something worthwhile, and we were all hoping to learn something useful about our service.
Instead, we faced an empty lab and a period of unwelcome down time. Our next participant wasn’t due for an hour and three quarters.
Thinking on our feet
Our solution was to give second-year graduate trainee, Merissa Brown, a rare chance to get hands-on with the usability lab.
But what came out of Merissa’s impromptu role play alongside a stand-in 67 year old (in real life 31-year-old Business Analyst Pascal Loiseau) took us all by surprise.
As it turned out, Merissa did fine. The surprise came from the other side of the exchange. Taking his role with commendable seriousness, Pascal found himself viewing the project he’d been working on for 8 months through completely new eyes.
Thinking out loud
It took Merissa walking him through the site for Pascal to fully appreciate the end-to-end journey his user was being asked to make. Until that point, he realised, he’d been thinking only about the technical aspects of individual pages.
As Pascal was quick to admit afterwards, talking his way through his interaction with the site really brought home how different a user’s perspective was from his own.
It also allowed him a freedom of expression that he found usefully liberating; “Being someone else gave me an opportunity to be freer in my responses. I could ask novice questions that I wouldn’t normally think to ask.”
It is a research cliché that the only bad questions are the ones that don’t get asked. Pascal’s role-play gave him licence to think critically in a way that isn’t always easy when you’re immersed in the detail and the politics of project work.
An inadvertent pay-off
“Honestly, I think everyone working on a project should do this,” Pascal said. “I really don’t think I’d have got as much out of it if I was just observing and taking notes.”
As it turned out, our 9.00AM no-show proved to be a less of a disaster than it might have been.
One of our stakeholders is now a much more confident advocate for the user’s perspective; a junior member of our research team has gained valuable experience in a usability lab, and we have all been given a striking demonstration of how useful something as simple as a casual role-play can be. That’s not a bad outcome from a 9.00AM no-show and an empty room.
Making time for inspiration
At NHS Digital we routinely get our stakeholders to role-play as part of our discovery process. It really can change the way people think. We now go out of our way to try to stimulate the sort of lightbulb moment that Pascal enjoyed whenever we can.
A formal role-play isn’t always practical, but we’ve see that you don’t always have to go to the lengths described here to enjoy those benefits. It’s never a bad idea to ask what your users might think or feel about about your service whoever you’re talking to.
Does your team regularly take part in role-play user research? How do you structure that, and what do you get from it? Let us know in the Comments section.
2 comments
Comment by Nikaesh Rattan posted on
The No Show need not be a Show Stopper. The NHS deals with F.T.A (Failed to attends) in a productive manner, as the Show must go on. It's admirable Pascal was stimulated by stakeholders as the NHS Digital is an amazing service. Having used the interactive android app I would recommend NHS Digital to all.
Comment by Hayley posted on
Thanks for sharing.
This is why it's useful for someone on the team to do at least 1 dry run of the service before testing with the public. Helps you empathise and spot any errors in the discussion guide.