Ever thought of why you might not be the best person to test your own (new) web application, website or digital product?
When developing any kind of web application, website or digital product, people tend to easily assume that they totally think and act like their users would. You know your solution best – you’ve faced the problems you’re trying to solve best, eh?
Wrong.
The more you know, the better: but not in UX
If you’re the one providing the solution, you’re always ahead of the users of your solution. Because you know how your application works, how to interact with it. You’ve designed it, you’ve thought it through, you have a mental model / an assumption of how people interact with it – that’s why.
With all that knowledge, you’ll never get the chance of that “first look” at your application again. You’ll always see it differently than a first-time user. That’s the curse of your knowledge.
Once you know something, you can hardly unlearn it or imagine how it was not knowing it. That’s why we find it so difficult to put ourselves in the shoes of our users. The people who interact with our application for the very first time. Thus, in the case of User Experience, the more knowledge isn’t always the better.
But how to overcome the dilemma of knowing too much? Definitely not by trying to guess the needs of a first-time user or their preferences. So, what’s better than guessing? Indeed: asking. Asking the right questions to the right people.
Why you need to ask the right people
Google knows the UX game. Google knows how to develop new products and optimize the experience for their users. And still, Google, at times, has failed to do usability testing right.
When Google has been working on “Buzz” to share photos, status updates, emails and such, they’d automatically connect you to people with whom you’ve been exchanging emails in Gmail.
They tested this feature with 20,000 Google employees. The more data, the better, right? You guess the answer: nope.
Google’s employees have a specific skillset and level of knowledge. They share a similar way of thinking and behaviour. Thus, by only asking their employees to test the new “Buzz” features, Google experienced a huge interaction design problem: “real” users complained about over-sharing and lack of control over their privacy. Something that resulted in declined trust for the company – and something that Google could have avoided by asking the right people.
So, don’t just look within your company or bubble, if you want to test your web application for user experience. Choose actual users instead to get the most valuable insights. Don’t be like Google on that. (Although they have a Trusted Tester Program – which hasn’t been used for Google Buzz.)
How to test for user experience
Now that you know WHO to ask for feedback, one question still remains: HOW? Let’s dive into UX research methods here a bit. There are various ways how you can have users test your web application. Depending on your research possibilities and preferences, you can either go for more qualitative feedback (from less users usually, but more in-depth) or for a rather quantitative method (with more users or data). Also, you can put your users either in the situation of actually using your application or have them answer rather theoretical questions.
Here is an overview of some most common UX research methods, not all used for testing though:
Let’s dig deeper into some of these methods you can choose from, depending on WHAT you want to find out and WHY:
Prepare some typical scenarios of what people want to achieve with your digital product and have some potential members of your target group perform these tasks while speaking out loud what they think. While you observe them doing that, you can ask follow-up questions on why they did things a certain way. This method will allow you to pretty much look into your users’ heads. Click to learn more about how to conduct a Thinking Aloud Test.
E.g., the System Usability Scale Questionnaire: The standard version of this questionnaire consists of 10 questions asking the user to rate how they think of the system aka your web application on a scale of 1 to 5. From the results, you calculate averages and ranges of how certain aspects of your system have been rated overall to see where it needs improvements.
Observing your users, as you would do in methods like a Thinking Aloud Test or Field Study isn’t always enough. You should back your observations by interviewing your users in order to not make assumptions about what you saw. By the use of interviews, you can find out more about the users’ background, attitudes, goals and desires, motivations, pain points, as our UX teacher Fleur Jeanquartier suggests. Your questions should always be specific and possible for the interviewee to answer.
Myth revealed: You’re not like your users
As we now discussed, the assumption that you’re exactly like your users is a myth. That’s why in most cases, it’s not sufficient that only you test the web application, website or digital product you built. Instead, ask your (potential) users to give you insights in their interaction behaviour. And by the way, if you make them feel like they can help improve something, they’ll gladly give you a glimpse into their heads.
Once you’ve defined what you want to find out from your users and why, you can read up on your preferred method of UX research and start your user testing. And you’ll be surprised what you can find out!
By the way, user experience testing might also help you find out if you’re using some kind of deceptive patterns. Learn more about these deceptive patterns in UX.