Answering Unanswered Questions

[00:00:00]
>> So with that in mind, when should we be doing this kind of research and testing? I'm saying there's lots of opportunities. Well, what are these opportunities? When your time and budget is limited, picking the most appropriate moments to do testing and research is crucial, right? The worst thing you can do is save it all up.

[00:00:22]
First of all, when it comes to user research in particular, and testing, actually, applies to both, avoid testing and doing research for the sake of it, right? So, one of the things that I come across all the time is people have read stuff online, right, they says you should begin with a discovery phase.

[00:00:44]
And in the discovery phase, you should do user research. And once you've built a prototype, you should test, and so people get to these points in the project plan, and they go, right, I've got to do user research. And then they do a load of use of research without a good reason, [LAUGH] without a specific thing in their mind that they wanna know.

[00:01:06]
We've got this tendency to carry out user research because that's what you're meant to do without any clear reason why, right? So don't do a comprehensive discovery phase without having a clear idea, for example, of what you wanna discuss, right? What you wanna know, general background research doesn't really provide the best return on an investment, right?

[00:01:31]
Instead, you wanna get answers to unanswered questions. So you've got a load of research previous stuff, you've been briefed and all the rest of it, write down a list of things you wanna know that you don't know, that's where you should be doing user research. So things like this, right, who are my audience?

[00:01:52]
What are their top tasks? What are the user goals? You can read what's on the screen. These are the kinds of questions that pop into my head when I'm working on a project, why I wanna know this kind of stuff. Some of it I'll have been told, in which case I don't need to bother researching it, some of it won't have been clearly answered.

[00:02:10]
So for example, you're almost always told who your audience is, but you never know what their top tasks are, what the most important things they wanna do are, right? They're never told that kind of thing. So it's kind of working out what you need answers to, and that applies throughout the project, right?

[00:02:26]
So as a question comes up, then do a little bit of research or a little bit of testing, rather than having this kind of formal process that you pass through. And I'm not criticizing those formal processes, I'm not criticizing discovery phases or anything like that, I'm just trying to be pragmatic and do the minimum we could get away with, right?

[00:02:47]
If you can do a discovery phase go for it, but oftentimes you don't get the opportunity. And the truth is, at the beginning of projects, you often don't know what the right questions to ask are. I never do, perhaps I'm just rubbish. [LAUGH] But the truth is, until you get into the weeds of working on a project, you don't really know what exactly you need answers to, right?

[00:03:15]
And things don't always occur to you upfront. I was working on a project recently and I was doing prototyping and going, I actually don't know whether they think that users think that this is more important than this. Which of these two tasks do they do the most often, right?

[00:03:31]
And which one do they want? And I didn't know. And I'd done a discovery phase, and for some reason that hadn't come out. So that's when you need to do the testing, is when the question is fresh in your mind, right? Also, use it as a great way of resolving disagreements.

[00:03:48]
This is the time that I always do testing, is when the moment comes, people start disagreeing with one another. Any opportunity, where people disagree, that's a chance to do usability testing or user testing. So, questions like, does it work? Most stakeholders will go, I don't think this is gonna work, right?

[00:04:09]
They don't really know why, okay? And you could get into this debate of trying to prove to them that it will work, or you could even try and reason them round and/or ask them why they think it won't work and all the rest of it. Instead of doing that, use it, say, well, let's find out, right, because it's an excuse to test much better than getting into a debate with them, or the kind of which is better?

[00:04:37]
One stakeholder has one idea, another has another idea, test it, let's find out. And then the final one is, will users like it, right? So design is so subjective, or certainly aesthetic design is so objective, and so subjective. So you wanna test that stuff, right? You wanna put it in front of people and test it rather than, one stakeholders saying, he wants it to be blue because he's always loved.

[00:05:12]
Blue is the corporate color, but then another executive goes, well, I really don't like that shade of blue. And it turns out to be because his auntie had curtains that were that shade of blue and he hated his auntie. You think I'm joking, but things like that do happen.

[00:05:28]
And then so they have an argument with one another and you end up with insipid green or something. Ridiculous scenario, put it in front of users, let them choose, let them decide. So resolving disagreements, that's when you wanna go in for testing. And then also where the information that you've inappropriate, is not the right word, right, it sound like it's dirty.

[00:05:52]
Rude, when somebody says it's something inappropriate, do some testing, know. When people give you information that actually isn't relevant or right, or you've got concerns about it, that's a good opportunity to test. So, a common one is, yeah, we did personas, here's our personas. When did you do them?

[00:06:13]
2017, I think it was, right? Okay, well, maybe we need to check that it's still relevant enough to date, or where people give you biased information, right? So you're often presented with survey results, and you look through the questions and you go, well, that was a loaded question, right?

[00:06:33]
No wonder they got that answer. So that's another opportunity to go back and say, well, perhaps we ought to just double check this, or you'll be given information that's just unfit for purpose. So personas are a great example of that actually. And often marketing teams will go, yeah, we did personas and they give you personas and it's like, this person reads the New York Times and drives an Audi and has 2.3 children and a dog, right?

[00:07:02]
Well, that doesn't really help me as a UX professional [LAUGH] right? So in those situations, you're gonna need to do different types of user research. So those are all opportunities to do research, but the kind of general rule is test early, test often, right? Don't save up your testing, I mean, one of the kind of go to books in the field of user experience design is Steve Craig's book, Don't Make Me Think, right, which is a superb book.

[00:07:40]
And he wrote a follow up called Rocket Surgery Made Easy, which is really good as well. It's actually very pragmatic about introducing facilitated usability testing into an organization without taking a lot of time or effort. But one of the diagrams from his book is this one, right? Actually, the more rounds of testing, the more problems you're going to uncover.

[00:08:06]
And the reason being is because of users will get stuck on the first round of testing, and they won't be able to progress far enough to find some of the deeper problems in the site. But if you then go away and fix those problems and testing again, then you'll uncover more problems that are deeper in the site or the application, right?

[00:08:26]
So actually more rounds of testing often work better, but each round can be more lightweight. So instead of testing eight users in one round of testing, you test three users twice or three times, right, and then ultimately you'll find more problems that way. Not only does it catch more issues, it also hides the cost, right?

[00:08:52]
Because if you're doing lots of little bits spread out through the project, people are less likely to notice the new turning around. And say, well, we need to Stop the project for two weeks while we organize a big, massive round of testing at the end of the project.

[00:09:06]
Where then the results come back and everybody goes, well, it's too late to fix all that now, right? So testing early and often. So in terms of testing earlier, there are kind of several key reasons for this. First of all, it's cheaper to fix because the earlier you find a problem that it's not been developed yet, it's probably in a prototype phase or where it's easy and cheaper to fix the problem.

[00:09:32]
Also fixing a problem earlier is faster to do, which means that the whole project gets to market faster, and then finally, it's easier to adjust, right? So if you've got find a problem earlier, it's much easier to pivot and adjust based on the feedback than it is once you've sunk a big cost into the project.

[00:09:53]
So a lot of the time, I'm doing testing when I'm designing, right? And I'm producing mock-ups like this one. So you end up with a kind of page mock-up of what your application might only be a single page, right? And these are great times to get in there doing testing straightaway.

[00:10:14]
And the tests are really easy, it's like, we're testing do they get it? Do they understand what the website is about, right? Do they know how to navigate it? And can they see it? Can they see the call to action or some specific thing? So when clients go, we need to make the logo bigger, is cuz they're worried that people won't see the branding, right?

[00:10:36]
Well, I'm not sure actually matters, but anyway, set that aside, you can prove the logo's bigger enough by doing a little bit of testing. Can they see the logo? Yes, they can. And then do they like it? So those are the main questions I'm looking to answer in the design phase most of the time.

[00:10:53]
Not particularly mind blowing complicated questions, are they, right? But those are the main ones you're gonna answer. During the build, once you've built pages and you've got something that's more interactive, then the questions become things like, can they find it, right? Does it answer their question? It's another common one, so oftentimes people are going to websites looking for answers to questions.

[00:11:21]
So, does it answer their question? And can they use it if it's got an interactive component? That is essentially all that you need to know, right? It's just different variations of that question. And then when it comes to, once you've launched the website, right? So what do you need to know there?

[00:11:40]
Well, again, it's very simple, you need to know, where are people dropping out of the site? What's stopping them from completing their tasks that they're trying to do? How can we increase conversion? And what will work better, this new version of it or the existing version? That's basically what it boils down to.

[00:12:00]
So all of our testing is basically answering questions, right? Once we get into that mindset of whenever there's a question, run a bit of testing, it goes so much smoother.