No Bad Users
Before we dig into how user testing can improve user experience (UX), I wanted to share that I’ve never been to a dog show. I have seen documentaries (and mockumentaries) about them, so there is some level of expertise here folks. But even with my vast knowledge, I was amused to learn that, according to rd.com “dogs aren't disqualified for jumping, barking, or even pooping in the show ring. Judges chalk that up to dogs being dogs.”
And that’s how I choose to think about user testing.
We can’t get mad when a user uses search instead of the menu, or looks for everything they can’t find in the footer. They’re just users being users. And we can learn a lot from them.
What Is User Testing?
User testing is an opportunity to connect with users, or a representative group of potential users, and put all of your design and product development work through the agility course. We give users a set of tasks and let them go free to try to accomplish them however they see fit. We just observe. It’s taking everything we already know about users and their habits and putting it together in a thoughtful way… and then watching as they prove everything we thought wrong.
Or right! I know we get it right sometimes too!
Why Is It Important to UX?
I would say that user testing is one of, if not the most important thing we do in the user experience process. In order to have user-focused design you have to listen to and observe users. A room full of stakeholders may have some great ideas and they may have amazing instincts about what users might want or need. They may even use the product. But they are still just one user, and any information that they may have collected is just anecdotal until we’ve observed it not once or twice, but over and over again. We design for people, not just one person.
How Do You Conduct User Testing?
If you’re going to start user testing, you need to have something to test with. Most commonly we’re talking about usability testing. So you want to have the product that you’re looking to improve, or a prototype of the product you’re looking to build. Then, based on your user research, (yes, always with the research!) you want to define tasks that the user would commonly complete.
Like the testing itself, there are various ways that you can observe. In the midst of lock-down, and even after, when testing for clients around the country, I’ve commonly utilized remote moderated think-aloud usability testing.
That’s a mouthful, but basically, I jump on a Zoom call with a willing participant and they share their screen and describe what they’re doing and thinking as I look on.
This is a great option because you can record the session and go back later to review. (Just make sure you ask before recording, but I guess we all know that by now.)
Start Off on the Right Paw
For the best results, make sure that you prepare the participant as best you can. For many people this will be their first time participating in something like this. There are a few parameters to be set:
- Make sure they understand that this isn’t a test in a traditional sense. They are not being tested, the product is, and there are no wrong answers.
- Encourage them to think aloud as they are completing tasks. This is a tough one for people, and you will likely need to remind them to do this as you proceed. Let them know that you’ll be able to see how the screen moves and what their mouse does, but you’d like to hear them describe what they are doing, or trying to do, and what they’re thinking about as they do it.
- Also a good idea to let them know that they can ask questions as they come to mind, but that you’ll make note and respond after the testing is complete.
- If you are using a prototype with limited functionality, tell them. Your design should support all of your assumptions about how the task will be completed, but no more. This allows you to test those assumptions.
I feel an example is necessary here to further explain. I’ll describe two versions of the scenario and let you be the judge.
Here’s the setup: You did everything in your power to set up amazing information architecture that’s reflected in your awesome menu. You tell the participant to imagine that they just heard from a fellow dog lover that a traveling dog show is coming to San Antonio which is very close by. They’re now on the dog show site, how would they go about finding out when the show will be in town? Your assumption is that users will go to “Calendar” in the menu and click on “Upcoming Events”.
Version 1 is you making your prototype completely functional: The participant begins and they see the search bar and immediately go there. They put “San Antonio” in the search bar and tap search.
Cool there it is.
Now this isn’t a complete loss. You’ll still walk away with one observation point supporting the idea that users expect to find when a show will be in town by using the search bar.
Now let’s say you only included functionality for your assumption of them going to Calendar and then Upcoming events. You let them know before beginning that this is a prototype and only has limited functionality.
Version 2: The participant begins and they see the search bar and immediately go there. They try to type, but it’s not functioning. So now you still have that observation from before, but since it didn’t work, they have to try something else. They scroll up and down the page and think aloud that since it’s coming soon, maybe it will be listed on the homepage somewhere. You now have a second observation, that users will scan the home page for information about current events. Then finally they see the Calendar menu item and navigate to Upcoming Events.
This is just one example of how sometimes less can be so much more.
As the participant is completing tasks you want to avoid providing guidance. They will inevitably have questions. And you can answer them… after the testing is done. There is one phrase you should make your best friend.
“Just try to complete the task as you would if I were not here.”
Oh wait, make that two…
“Just a friendly reminder to think-aloud as you’re completing the tasks.”
Takeaway: Don’t Screw the Pooch
Resist the temptation to overload your user testing. This can be testing too many things at once, or having too much going on in your prototype that is not related to the tasks.
Remember that at this stage it’s okay for users to be frustrated by your product. You may have made excellent choices, just not right for these users. Be grateful that they were willing to struggle so you can learn. And say thank you! Remember that you’re also going to make it better for them, so that’s something! Plus as we learned earlier, even when you poop in the show ring, you’re not a bad dog.
At Inventive we encourage user testing throughout the product development process to ensure that everything we build has first been validated by the user. This can result in incredible savings by reducing engineering costs down the road. Either way, users are going to tell you what they like and don’t like about your product. Why not have them do it before you step in the show ring! Reach out to learn how Inventive can help you to be the best in show!
