UX Research & User Testing

Testing Prototypes

Paul Boag

Paul Boag

UX Research & User Testing

Check out a free preview of the full UX Research & User Testing course

The "Testing Prototypes" Lesson is part of the full, UX Research & User Testing course featured in this preview video. Here's what you'd learn in this lesson:

Paul discusses the importance of prototyping and the opportunities for testing that come with it. He explains the benefits of realistic and interactive prototypes and discusses the options for usability testing, including facilitated and un-facilitated testing. He also explores the pros and cons of remote testing versus in-person testing, and highlights the importance of testing specific aspects of the prototype, such as navigation, learnability, efficiency, and satisfaction.


Transcript from the "Testing Prototypes" Lesson

>> Right? Let's talk prototyping. So now you may or may not do prototypes. If you don't do prototypes, that's fine. Not everybody does them. If you're a smaller project, then you might skip the prototyping stage. But if you do do prototyping, there is a lot of good opportunities for testing here as well.

So, why bother testing with a prototype? First of all, a prototype is it's realistic. A prototype much more closely represents the actual user experience. And so it's a great opportunity to get realistic results about how a user will interact with something. Second thing, it's interactive. A prototype provides an opportunity to test where a user can actually interact with something.

And I came across this recently where we got mockups of pages in Figma, but we were spending so long trying to explain how something would behave. That in the end I just said, well, let's build a prototype of it. Cuz this is just getting ridiculous, trying to explain everything.

And it's also really good for longer journeys. So, for example, if you've got a kind of a series of steps or a flow that a user needs to go through, like a checkout process or something like that, where it's over multiple pages is much better for that kind of thing.

So prototyping has it's definitely has its place and can be a really good place to do some testing, tends to be slightly bigger projects often, but it depends. So, what are our testing options here? Well, one option is facilitated usability testing. So in this, you basically sit down with the user either in person or remotely and you ask them to complete series of tasks, select a product that you liked the look of and buy it, right classic e-commerce checkout kind of thing.

And as they're going through it, they'll go quiet. They won't say anything and you're so what are you thinking? Well, they're pause at a certain point and you'll go, why are you pausing there or they're pull a face and you say what was that face about and things like that in order to encourage them to express what's going on.

The other alternative is unfacilitated testing, where participants are given the task, but there's no moderator to prompt them. So they're encouraged to think out loud during the interaction and it's recorded, so that you can watch it back afterwards. So both methods are perfectly valid, but they've got their pros and cons, right?

So unfacilitated testing, where you just give them a link, they're recorded while they do the tasks, but you're not there watching them. It's easier to run, right? You can do it with more people because you don't have to sit in on each of the sections, intends to encourage more natural behavior because there's not someone leaning over their shoulder saying, why did you do that?

And which is a bit weird. And you tend to get faster results, right? Because you can you don't have to sit around waiting range for people and all of that kind of stuff, you just throw out the URL and they get results back quick. So that kind of testing is really good for what I call, is it working, testing, right?

Do people understand it? Can they use it? Can they complete the tasks, right? Great for that kind of stuff. While facilitated testing, when you're sitting with them interacting with them, it's great because it's a more guided interaction, right? So you can prompt them, especially if the prototype is a bit junky, [LAUGH] right?

If there's bits that don't really work very well, it's quite nice to have somebody there that goes, yeah, that's broken. Don't worry about about it, go back to the previous page, that kind of thing it's useful for. It's more adaptable. So, in other words, you can as something's going on, if they go and do something strange, you can kind of go with them and and ask them why they're doing that and what they're thinking is and kind of adapt to whatever they're doing.

It's easier to get clarification cuz sometimes people will say something out loud and you think, well, what did they mean by that? So it's good for that kind of thing. And it's great because it's easier cuz you're sitting there looking at them throughout it, you tend to pick up their nonverbal cues better than watching a video back afterwards.

I don't know why, but it seems to be the case. So I consider this better for the, why isn't this working, testing, [LAUGH] right? So, it's a subtle difference, but unfacilitated testing will show you whether something is working or not. Facilitated testing will show you why it's not working, will explain what's going on clearer, if that makes sense.

So that's your choice, facilitated, unfacilitated. But then there's also remote testing, right? Do I bring in the people and sit them in a room or me go out to them physically or do we just do it all online via Zoom or some other option? Remote testing is great cuz you tend to get a broader reach and diversity, right?

Because you're not stuck with geographic locations as a problem. It's also more cost-effective because you don't have travel and you don't have to pay for them to come here and all the rest of it. More efficient for your scheduling or scheduling. What is it you say here, well, one or the other one.

>> Scheduling.
>> Scheduling, anyway. And also it's highly scalable as well. You could do a lot of different people quite easily. The downside of remote testing is you can have technical issues where somebody gets stuck trying to use the kit and you're not there to help them, and you see you can have problems like that.

You get limited control over your test environment, which sometimes can be a good thing and sometimes it can be a bad thing. So what I mean by that is sometimes say you're doing a mobile testing, for example, they might have some obscure phone that most people won't have.

And so you don't have control over that, and that's kind of sucks. But on the other hand is kind of more realistic if you don't have control of them. I did a great usability testing once where the woman was doing a whole usability testing with a toddler sitting on her lap, right, which is what happens in the real world.

So it was kind of quite interesting in a way. Non-verbal cues are harder to pick up when it's remote. And there are much more examples of potential distractions like toddlers and cats and doorbells going and things like that. So use pros and cons on it. Most of the time these days I do facilitated remote usability testing.

It's quicker, it's faster, I can get more people, I'm lazy. It just depends on the project and it depends on the budget and that kind of stuff. Just by contrast, in-person testing, you get richer qualitative feedback. So you get to meet the person and see the person, and even what they're wearing and what shoes they've got on, and it all builds up a picture of who somebody is.

The best is if you go to their place, their house. Then also there's in-person testing, you can control the environment if they come to you, you can have everything set up, although that can backfire on you as well. We once did a testing, we had a big iMac there with the mouse to the keyboard all set up for them to do the testing, and we were testing old people and none of them knew how to use a mouse because they'd all been given laptops with trackpads.

And so that kind of screwed the whole day's testing cuz we weren't letting them use their own equipment. Anyway, that's another story. You get better engagement through in-person testing, which I love. You kind of can relax people and get them on board a bit more, you can get immediate clarification, but it costs more.

There are geographic limitations, there are scheduling challenges, there are scalability issues. I would love to do in-person usability testing more than I do, it just doesn't happen a lot of the time. So either way, whatever kind of testing you do, it's more important what you're testing, right? You've got a prototype, you wanna do some usability testing, and usability testing is normally the best way to go on a prototype stage.

What are you trying to look for? Well, you're trying to establish how easy it is for users to navigate and understand the prototype. So it's about easy to use, kind of obvious really, isn't it? I'm gonna do usability testing and see if it's easy to use. Navigation is the other big one.

Is prototype easy to navigate? Are they logical and consistently placed to people? Are they where people expect them to be? Then there's learnability stuff, how fast do new users understand the prototype and pick it up? Sometimes if you find yourself having to clarify a lot of things, or they sit there kind of looking at it, or you know that things are not going well.

Then there's efficiency, how efficiently tasks are to complete. This is particularly important if you're building an app that people use regularly. So, for example, at the moment I'm working with an insurance company where you've got underwriters assessing hundreds and hundreds of assurance claims. And they're going through these one after another, so obviously, it's really important that they can do that quickly and efficiently without too many clicks and stuff.

And they let if you haven't got it right, I can tell you that. There is satisfaction. How likely are users to use the prototype if it was a real product. You can actually ask them that. You can look at things like accessibility as well with screen readers, keyboard navigation, different mobile devices is another good one.

It's all kinds of different things there. Content comprehensibility. Is that a word? Is word, isn't it? Is the text content easy to read and to understand, that's another great opportunity to do that with prototyping. Then there's things like I spend a lot of time testing conversion paths, so I do a lot of conversion rate optimization work.

So checkout processes, contact forms, that kind of thing. They're great. When you get a user interacting, like with data entry or something like that, that's when things often go wrong. So they're always a really good point to look at. And indeed, any interactivity, how error handling is often a really interesting one.

When people make mistakes in an interface, how the interface adapts to that. So there's loads of different things you can test. What you test is largely what you're worried about, is what it boils down to. What are the bits of the interface that you're worried about? And again, don't run usability testing just for the sake of it.

Run it when you've got questions and concerns, that's the moment to do it. When you think, I'm a little bit unsure about this, or someone else is unsure about it, that's when you wanna jump in and do some usability testing. In terms of who to test with, again we're back to that, that as long as they're competent and have got the same kind of ability spectrum as your end user, anybody will do.

So usability testing, friends and family again, you can see why they get sick of being asked. My friends and family have less friends now because of the result of this, but anyway. The other thing you might wanna think about is if you do big projects that last months of developing something that's quite complicated and quite big, you might wanna think about the number of rounds of testing that you do?

So, one of the big things, I mentioned this book earlier, Steve Cruise book Rocket Surgery Made Easy. One thing he proposes is, look, if you're working on long term projects where you're developing a digital service over the long term, then you might wanna have like a day a month or morning a month, only needs to be a morning where you tests with three people and the same, the third Thursday every month or whatever.

You just test with three people that Thursday every month, whatever the questions are, whatever the concerns are that month, you get in a routine of doing it. And he actually suggests that you open that up to anybody to watch and that you test three people in the morning, everybody watches and then everybody sits down at lunch and says, well, what are we gonna do about these problems?

And you bribe them to come to the whole thing with pizza at lunch, right? I mean you guys all turned up just for the for the chipotle so it works internally, pizza can get you everything. So, yeah, usability testing is great, it's a really good tool. The remote unfacilitated is lighter weight.

If I could do a little bit more than remote unfacilitated it would be remote facilitated, it's the in-person thing that's the real luxury, right? If you ever get one opportunity in your life to go to someone's home and test with them, do it. It's frigging awesome. You'll love it, yeah.

>> Yeah, you're ringing a story with me. Before remote thing was even a thing, [COUGH] and the first time I wrote a fun end application was with the Ramsay County Sheriff's.
>> Right.
>> Department, I actually wrote the DUI logging system for the squads.
>> Okay.
>> And I would ride with the deputies, and I did this too late.

So I wrote the application, the front end, but some of them were were complaining because they couldn't, their fingers were so thick.
>> Yeah.
>> That they couldn't click whether it was a DUI stop or was it like a warning of some sort?
>> Yeah.
>> I got that feedback late.

>> Yeah.
>> I made my drop down o a bit too skinny.
>> Yeah.
>> But it's having that opportunity to work with someone is so impactful in their environment.
>> It really is.
>> Yeah.
>> I mean, the best one I ever had was I went to, again, I was working with old people at this stage.

And so I was visiting, I went to them because a lot of them had mobility issues and stuff like that. And I went to this one lady's house and she opened the front door and this stream of cats came out. She was really a stereotypical cat lady. And every surface on the whole of our house was covered with cat ornaments, like nicknacks, well, we call them nicknacks ornaments.

And we sat down at a computer and it was like, we're cranking up desktop computer that took half an hour to get, eventually this thing got going. She sits down to do the usability testing, but immediately a cat jumps on her lap so she's got a cat on the whole time.

And then the mouse, she had so much clutter on her desk that she had like this amount of space to move them out. So she was going like this the whole time, picking it up and moving it. And the real killer moment was I said, okay, select a product that you like from the website and add it to your basket.

So she picks a product and adds it to a basket. And I was about to say the words, now go to your basket and check out. And I thought she ain't gonna be able to find the basket, because she had posted notes all around the monitor that was covering up where the shopping basket was.

I mean, how you design for that, I don't know. [LAUGH] But it was so enlightening to actually go and meet these people, it's actually worth it, but you just can't justify doing it all the time or at least not on the kind of projects I get to work on, and I get to work with big clients.

So you'd think if anybody could do it, it would be my kind of clients, but they go.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now