Sat in on a few user testing sessions today and it struck me just how unnatural it is to be a facilitator.
Your team should have User Researchers. Designers shouldn’t facilitate sessions, but sometimes we’re left with little choice. So the best thing you can do is give your design a chance to be tested properly, but there are some rules!
These may seem obvious, but you’ll be surprised at just how hard they can be to follow through with, especially under what can seem like fairly pressured conditions of a user testing session.
1. Prepare a scenario
Be prepared. Unless you’re lucky enough to have the time to build a dynamic prototype, it’s likely to have hard coded data in it, so do yourself a favour and set out a scenario for your user to follow, that way, when they see a summary screen, they won’t be surprised to see something they didn’t enter.
2. Set the scene
Introduce yourself and the service. Be sure to tell the user that you’re not testing them, you’re testing the design or the service that’s been created and how it works for them.
3. Get thoughts, not opinions
Ask the user to speak out loud about what it is they’re doing and what they are experiencing when they go through the screens. From the outset, tell the user that you’re looking to find out how the service works for them and how they interact with it. You’re not looking for opinions on how it was built.
4. Let the user use it as they would if they were left alone
The key thing is to get a clear idea of how the service works for the user, or how it doesn’t work. The only way you can do that is to test it as if it were in real world circumstances. So let the user go through it from start to finish without interference and questioning — this it’s important to set a scenario at the start.
5. “What do you think will happen next?”
I’ve found that letting the user go through the journey once, alone, gives me most of the information I’m looking for, but if necessary, will ask the user to go through the journey a second time and will tease more information out of them with further questions.
If you must ask questions on the first time around, you may want to ask what they expect to happen next, before they proceed to the next step in the process. Other questions are unnecessary and can probably wait until a second run through.
If there is a golden rule, this is it. When asked by a user “is that correct?”, a good way to answer would be “is that what you’d expect to do here?” — or a similar response to similar likely queries. It throws the ball back into their court and ensures that you’re not leading them.
6. Resist the urge to say something
Not saying anything is probably the hardest thing in the world, especially when you’ve designed something and you’re willing the user to “just look a little further down screen!”. But it’s critical that you keep your thoughts to yourself.
If you start saying things like “that’s really good feedback” or “yes, that’s great” when a user asks you if they’ve done the right thing, you run the risk of them performing certain actions to please you, the “interviewer”. Don’t forget, you’re a facilitator, not an interviewer. So keep it as formal as possible, don’t react and remember to resist the urge to lead anything.
If you’re a designer and facilitating, resist the urge to explain design decisions. We’re testing this service and the focus should be on getting as much out of testing it as possible.
We are used to engaging with people as we talk and so it can be easy to interact in a way that can affect the results of the test session.
Note: Sometimes users get really stuck and as a facilitator, you need to be the one to help them out, this is perfectly natural and it’s ok to help move them on to the next page. Only do so if you’re sure you’ve learned everything you need to learn about what it was they found difficult.
7. Keep distraction to a minimum
Like I said earlier, if you want to question why a user did something at a certain point in the journey, that’s fine, but leave it until later. It’s absolutely vital that you get a clear view of how a user interacts with what’s in front of them without any interference.
8. Enquire without leading
The number one crime when user testing is to ask a leading question. Don’t do it.
Example, “Did you find it easy to continue to the next step?”.
Regardless of the fact that it’s an unnecessary question (you can observe such behaviour, if testing is executed correctly), this puts the user in the awkward position of having to say that maybe it wasn’t easy — all feedback is good for us, but the user may not like to give negative feedback.
9. Take lots of notes
The facilitator traditionally wouldn’t take notes, that’d be the job for observers in another room. However, on the occasions where I’ve facilitated, I’ve found it helpful to take notes as it helps me stay quiet, even when things get awkward. You’ll need all the notes you can get your hands on for summarising the feedback you’ve got.
10. Share observations not opinions
When summarising the user feedback, be absolutely sure that you’re conveying exactly what you saw, and what you learned — not what you thought was a potential fix for a particular problem you observed.
Example, user fails to do enter a date of birth correctly, so the insight was to “use a date picker”…There are many things wrong with this approach, not just the solution that the designer has come up with. First and foremost, be sure to observe and not solutionise, in your feedback.
It’s important to separate solutions and insights from actual factual observations. That way, it’s easier to have an open mind when tackling issues that users have come up against. The example above may seem like you’re using a sledgehammer to crack a nut, but show a stakeholder that feedback, and they’ll really push for a date picker to go into the UI…nobody wants that!