Meanwhile, a lot of company’s building (digital) products have embraced (or at least accepted) the positive impact user testing can have on the product development process. But just because you somehow involve users into your processes, doesn’t mean you’re doing it right.
Personally, I had the luck to get great teaching into the art of user testing from my former colleagues Britta and Anne. And while you can and have to divide user testing into its separate domains (research, deep interviewing, usability testing), I want to point out 3 very common misconceptions which I stumble upon in early discussions.
Focus Groups are the shit!
Nope, they’re not. They’re actually one of the worst ways to get feedback on your product or getting to real user struggles (right behind building assumptions just on your own behavior). When it comes to pointing out failures of a product or negative struggles, people are her animals. They’ll follow the most common opinion in the room and will be too embarrassed to be the first ones acknowledging a mistake or flaw.
Only personal situations and a comfy and trustworthy environment will bring you closer to see the real behavior of people and hear about their true struggles.
If you want to have the room full of like-minded customers of yours as part of your product creation process, I instead recommend the format of Co-Creation Sessions.
Personas are a great way to figure out my users needs
While personas are already quite an improvement for user-centered products, I still think they have a huge flaw: They focus on the wrong things and distract you!
Building up on what the smart guys behind Inside Intercom have written about why Job Stories beat the format of User Stories, I want to apply to the format of personas. Conducting the corner stones of a ‘traditional’ persona (age, hobbies, family status, hopes & dreams) takes way too much time (or is purely based on imaginative stereotypes) and doesn’t give you any tangible entry points for figuring out around which problem your product should be built.
Instead, you start chasing constructed touch points in a user journey far off a users core problem (you’re able to solve). Instead, you should almost entirely focus on the context and core problem which will inevitably lead to a certain ‘job‘ people hire a product/workflow for. After figuring those two things out, the demographic data of your target group becomes highly irrelevant.
If you want to apply a persona-style approach at the beginning of your product discovery anyways, I’m a strong advocate of Proto-Personas. This format will keep your efforts focussed on demographics reduced to a minimum and will include some reality checks.
We’ll just ask them what they want and how much they’re willing to pay for it
While I can’t stand the iPhone comparison when it comes to user research (‘Steve Jobs never asked anybody, whether someone wants an iPhone), there’s a certain point in it: Users are not able to articulate the right solution to their problems. This is why you are a tasked with building products which serve their needs. But in order to get there, you have to entirely focus on problems and not potential solutions, when talking to users before even sketching a first wire frame. Don’t ask them what they want (even if it itches you to shout this question at them after they’ve neglected 6 of your fancy prototypes) and rather focus on what makes them happy or grumpy.
And while you’re at least able to derive some valid qualitative data from talking to users about problems, you won’t be able to when it comes to monetization. Sure, you’ll get close to figure out a person’s most important product attributes which makes them paying (e.g. quantity over quality or cross device availability), but whether they’ll pay in the very moment for your product needs to be determined outside of that interview room (I’ll talk about quantitative validation at a later point).
Which misconceptions about user testing are you giving you a hard time to get out of people’s heads?