Testing Assumptions with Usability Testing

[00:00:00]
>> Just to explain why I like to do a little bit of upfront testing. First of all, I like to do it to check assumptions. A lot of people come to you, we've decided we want to redesign this app. Why? Cuz we think the app is rubbish. Okay, why do you think it's rubbish?

[00:00:20]
Well, because we've looked at it and it's rubbish. All right, well, let's just check that assumption, that users think it's rubbish, right? So that often why I tend to do a little bit of up front just to kinda validate the project. I also like to do at this point because there's low cost to it, right?

[00:00:40]
You don't need to build anything, you're just testing what's already there. [LAUGH] So it makes the testing less expensive and time-consuming to do, which is always a great thing. And then also, it can be quite a good opportunity to do a bit of a SWOT analysis, a chance to identify strengths, weaknesses, opportunities and threats with what's there already.

[00:01:00]
So it's quite a good opportunity to do some testing, if you can crowbar it in and get permission to do it. If you do testing at this stage, typically, I'm looking for the following things. Do they get it? Do people get what this thing is, this app is, this website is, whatever?

[00:01:19]
Can they use it? Fairly basic, can they find their way around it? Can they find a particular piece of information they want? Does it answer the questions that they have? What frustrates them about it? What do they like about it? That's all I'm trying to find out at the beginning.

[00:01:41]
And if I do do that upfront testing, oftentimes I'll do it through usability testing. So this is typically where I will test probably three to six people, if I can swing it. Three is a minimum, if you're gonna do less than three it's probably not worth it. But if you can't do six, then fine, but as we said, you get 75% of the problems at three people and you get something like 95% of the problems at six.

[00:02:09]
So if you can do six, great. There's two ways you can do it. You can do facilitated testing, and that's my preference at this stage, if you can, where basically you're guiding users through the process. Asking them questions along the way, what do you think of it, and getting them to complete a series of tasks while they're doing that and speak out loud about that experience.

[00:02:32]
And facilitated testing is great to get to know users and understand the issues they have. Often kind of combine a kind of user interview with the usability testing at the same time, and do it as one session. And it's a great way of kinda getting a feel for the project.

[00:02:50]
If you can't do that because you haven't got the time, right, because obviously, you've got to sit there and talk to these people for 40 minutes a pop, probably. And then, you might not have time to do that. So the other option is facilitated testing, where users complete tasks independently while being encouraged to think out loud about what they're doing.

[00:03:13]
And I'm gonna come on a lot more about how to do these tests later. The unfacilitated testing allows you to test for more people, because you don't have to sit through every session, which can be nice, but the insights aren't quite so deep. So upfront I don't tend to favor it so much, un-facilitated testing tends to work better later when you've got prototypes and things like that.

[00:03:37]
But you do what you can. I won't say it again, but you know what I would say. Alongside usability testing, I'll also do a quick bit of monitoring, looking at the existing data that exists around the site, if I can find time for that. So typically, I'll jump into analytics.

[00:03:58]
And as I said before, I look at why users are abandoning the digital services, the big thing I wanna know, then I'll jump across into Hotjar and Microsoft Clarity, that I mentioned earlier. Which have got heat maps that can show me where people are clicking, how far they've scrolled, all that good stuff.

[00:04:16]
That can often be really enlightening, cuz you can go, well, people are already scrolling a third of the page, no wonder they're struggling to find things or, why are people clicking on this thing that's not clickable? That kind of stuff comes out with heat maps. And then if I'm feeling ambitious and I've got a little bit more time, I watch some sessions back, right?

[00:04:38]
So you can actually watch real users interacting, as we were talking about earlier. And I will look particularly at users that have struggled for some reason, rage clicks. Those that have abandoned the site early, those that have clicked on things that are unclickable, those that have caused an error or whatever else, and you sit watch some of them, see what they did.

[00:05:03]
There's gonna be a lot more on this kind of live testing, where you're testing something that already exists later, but that's pretty much where I wanted to, leave it for now. So that's what I tend to do upfront on projects, a little bit testing, little bit getting to know users.

[00:05:21]
Yeah, go for it
>> Yeah, well, I like these, there's a couple of things that I've really picked up on, some tips, journeys, in particular. But I do wanna mention that [COUGH] anytime I go into a project, I figure out the stakeholders, as a mobile developer.
>> Yeah.

[00:05:37]
>> I figure out what device they're using.
>> Yeah.
>> Are they Android, are they iOS? What version are they using? And kinda like, what colors do they like? But I use that so that I know if I can get them attracted to a certain feature or what flows they're having problems with with the current application, I can attract them to come back into the meetings.

[00:06:00]
Cuz I'll say, X is having these problems. Look at the flow, here's what's happening, and we're trying to solve this.
>> Yeah.
>> Knowing the stakeholders' devices has helped me a lot to get them encouraged.
>> I'm with you now, you're actually saying, yeah, what the stakeholder is seeing.

[00:06:16]
>> Yeah.
>> Yeah, yeah, I get it.
>> Yeah, yeah, yeah.
>> Good.
>> Yeah, I mean-
>> Knowing your audience.
>> Yeah.
>> Also knowing your stakeholder's-
>> Yeah, yeah.
>> Device. And if they're not using a device, for example, in a website, some people have preferences over Safari versus Chrome or whatever.

[00:06:31]
So trying to figure that out first, because sooner or later down the road, they're gonna test it.
>> Yeah.
>> And they're gonna say, this is a problem, and obviously, we miss it, because we're so busy with the other stats, but that part helps a lot.
>> Yeah, I totally see where you're coming from.

[00:06:49]
I mean, obviously it could be a dangerous road, cuz you don't wanna just design it for your stakeholders, but you're not suggesting that, you're just suggesting it's worth knowing. Yeah, I totally agree. Knowing your stakeholders, knowing what makes them tick. The other thing I often, what is there, every person within a company typically has a thing, a pet project, a pet thing that they care about.

[00:07:13]
They might care about revenue or they might care about efficiency or whatever. And I just frame everything I ever say to them within that context. If we do usability testing, it will make us much more efficient. You're pandering to your audience, yeah, we've got questions either online or-

[00:07:31]
>> Yeah, no, it's just-
>> It's you again, is it?
>> Yeah, it is.
>> [LAUGH]
>> Just overall, I'd say that with, in Frontendmasters in general maybe this is unique to us. But I think whoever talks to the customer at the most, whether it's customer service, whether it's usability testing, whether it's, any interaction with the customer, customer interviews, etc.

[00:07:55]
I feel like it has generally, the biggest influence when it comes to meetings about what we're gonna work on next. Or when there is a disagreement of what we should build or whatever, it's like, if somebody frames it from, well, the customer said this, they always win, [LAUGH] no matter who in the company says it.

[00:08:16]
It's like, yeah, if that's what the customer is saying, that's what we need to do. Rather than, I feel this or I think this or whatever.
>> Yeah, and you'd think that would be blindingly obvious, but it's not the norm. It really isn't. Most organizations, it's often the person furthest from the customer that is making most of the decisions.

[00:08:37]
The person that is the most senior in the room. And the senior person is almost always the person that has least contact with the customer. It's crazy, but it is the way it is in most organizations, not so much with smaller. The smaller the organization, often, the closer the founder is to the customer.

[00:08:59]
But the bigger the organization, the less it's driven by user-centric thinking. And you have to kind of really enforce that in the culture. So take, for example, the UK government. The UK government, when they set up their digital service, they created a policy that said, you cannot be a stakeholder on a project unless you have done, now, let me get this right.

[00:09:29]
Two hours of usability testing, you've been sat in the room with the user for two hours in the last six weeks. So basically, you were ruled out from having anything, but they had to really fight for that, to enforce that kind of culture, and it's just not that common within organizations.

[00:09:50]
I wish everybody was like you guys, cuz that's the way it should be. So really, with this whole upfront user research, if you're gonna do it, keep it really lean, hike the cost if you can, sneak it in if you can, but don't overdo it, don't do it for the sake of it.

[00:10:10]
But do take the time to identify your audiences, have a good understanding of who they are, and very much trying to understand their needs. And yeah, if you've got a little bit more time and a little bit more budget, then consider doing some mapping of the customer journey and some testing as well, if you can squeeze it in.