User testing for bad dogs

How user testing can improve user experience, even when they shit on your design

This article is day 21 of a 31 day series. A mash-up of the Inktober 2022 prompt list and UX terminology. Read more about the challenge here.

Day 21 | Inktober prompt: Bad Dog| UX Term: User Testing

Bad dog!

I’ve never been to a dog show. But I’ve seen documentaries (and mockumentaries) about them, so there is some level of expertise here folks. Even with my vast knowledge, I was surprised 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.” I think that’s a good way to think about it when we conduct 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 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! But that’s not as funny.

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 be someone that will 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. I’ve said it before and I’ll said it 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 complete commonly.

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. Meaning 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 and go back to review. (Just make sure you ask before recording, but I guess we all know that by now.)

Start off on the right foot

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 design 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 that they’re looking for. 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

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 it’s okay for users to be frustrated by your design. 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! You’re also going to make it better for them, so that’s something! As we learned earlier, even when you poop in the show ring, you’re not a bad dog.