Whether you’re testing an existing product, involved in a site redesign, or working on a completely new site, your biggest challenge is often yourself. Here are a few ways you might unintentionally cause problems:
- Your personal experience with a company, product, or application skews your interpretation. Think about an application you use daily. You know exactly where it frustrates you the most and maybe even how you’d fix it. Now imagine you were hired to make improvements to that app. You’d want to go straight to the source of your frustration. But if you limited your testing to just that area, you could miss a more global and crippling problem because of your tunnel vision.
- Years of experience using and working on the Web helps you to become an expert, but it also can create blind spots. Assumptions about how the Web should function based on what has worked and failed in the past can be indispensable, but also dangerous. When doing realistic illustrations, artists say, “draw what you see, not what you know,” and this is the same principle.
- Lots of pressure from higher-ups in a company to affirm their theories can implicitly affect the way you run tests and ask questions, especially if you’re new. There’s a reason people can be skeptical of tests funded by pharmaceutical companies. You may never skew results on purpose, but it’s easy to do unintentionally when the stakes are high enough!
Whether you’re conducting formal usability testing or just meeting with your team to discuss wireframes, your deeply held convictions can influence you anywhere! Here are some ways to actively work against your biases:
Avoid asking leading questions
Such questions hint at the answer you’re expecting to receive. For example, analyze how the statement below may be leading:
I would like you to use this form to complete your order. Your card won’t be charged when you click the submit button, so please finish the whole process.
The leading is subtle, but the statement assumes that the person using the site knows that you’re supposed to click a button at the end of a form, and that it’s called a submit button. Even more subtle is that just by saying the words “submit button,” you’ve now likely caused your participant to give more attention than normal to that element.
Be empathetic to participants
Your testing will be most successful if you recognize the strong desire many people have to do a task properly. Constant apologizing will likely make the test run too long, and can make for a stressed-out participant (making you feel awfully mean).
By paying careful attention to your tone, and writing an assuring and informative script to lead into sessions—as well as gently reminding participants during the session that you’re testing the web site or app, and not the individual—you’re more likely to create an environment that produces impartial results. If the participant simply struggles to figure out an interface you made and thought was quite clear, you’re at an especially high risk of becoming defensive, or asking leading questions to achieve an expected outcome.
Beware of your assumptions and bad memory
As soon as a test session is over, your brain starts to fit the new information into your existing assumptions about how things work, forgetting or altering those new pesky details. The steps your brain takes to remain efficient do not always lead to the most accurate synthesis of information—especially if lots of time has passed between project stages. It’s impossible to remember everything that happened during the test accurately, even if you are a good note-taker (although, notes help!). Consider recording the screen and audio during sessions at least, so that you can refer back during analysis.
There’s no need to stress too much over these things, but do learn to be wary of your inclinations over time. Your best tests and internal discussions will happen as you learn to remove your biases from them.