The Product Design Process

Testing Your Prototype

Paul Boag

Paul Boag

The Product Design Process

Check out a free preview of the full The Product Design Process course

The "Testing Your Prototype" Lesson is part of the full, The Product Design Process course featured in this preview video. Here's what you'd learn in this lesson:

Paul discusses the importance of testing in product design and how it should be done throughout the development cycle rather than just at the end. Paul shares his approach to testing, including testing wireframes, mock-ups, and prototypes, as well as post-launch testing for exit points, friction points, and new functionality. He provide tips on recruitment for usability testing and mention the availability of testing tools that can help with participant recruitment.


Transcript from the "Testing Your Prototype" Lesson

>> We talked about prototyping. I've had a bit of a rant about how people organize their Figma files that out of the way. Let's talk about testing for a little bit. Now, I will say I'm now trying to cram a four-hour workshop into one small section, so I would encourage you to go away and watch the other workshop.

But I will kinda briefly touch on the role of testing in product design and how it kinda fits in with prototypes and what kind of testing you can do at different stages. Very briefly, obviously, testing is essential to product design. It would be madness not to test your product if you need to justify it to anybody who doesn't know better.

After you've given them a good slapping, you can tell them that it leads to better products. It's useful in resolving arguments, and ultimately, it's gonna save you money. So it's a kinda no brainer really, but you have to say these things. I personally, a fan have lots of lightweight testing.

I'm not a fan of what often happens, especially in larger, more traditional organizations where all the testing is saved up to the end. That seems like madness to me, because the end is the most expensive time to test. Because if you find anything, well, you've already built everything, so the cost of changing it is gonna, be really high.

And also, if you test a little and often and early, you tend to uncover more things. Steve Crew covered this in his book, Don't Make Me Think, from where this illustration comes that basically. The crux of the matter is that if you just do one round of testing, people get stuck, and then they don't see problems deeper in the app because they never get any further.

Well, if you do multiple rounds of testing, then it gets a lot easier. So do lots of lightweight testing is my advice, test early is my advice. Leaving testing to the end of the project is pointless, really, as I just said. In terms of opportunities to test, I think the further you get in the development cycle, the higher the costs become.

So testing in the design phase obviously makes a lot of sense. As I said earlier, I don't test paper prototypes, cuz I don't think they're very good for testing. I know other people would disagree with me and think that you should be testing with paper prototypes. If you've managed to get it to work good on you, you're a better designer than I am.

And I haven't managed to do that particularly successfully, but I do test wireframes quite a lot. And also test mockups, even mockups of single pages, single screens, and an app. I think there's definitely room for mocking up those, and then obviously full blown prototypes I definitely test. Then once we move into the build phase, I will do a bit of testing at this stage, especially if things have been changed from the prototype tend to focus on navigation at this point, functionality as well.

The key things, can people find stuff? Are they successfully finding their way around it? So I'll do a little bit at that stage. And then post-launch, I tend to do quite a lot. Even though the cost is higher for change at this point, there are a lots of opportunities to make small changes that aren't necessarily that expensive to do.

And so I look for things like exit point where people are abandoning the app. I'm looking for friction points where people get frustrated using the app. And obviously any new functionality that gets built would need to be tested as well. I favor a very pragmatic approach to testing.

The testing something is always better than testing nothing as long as you're aware that your testing isn't necessarily perfect and you might introduce biases. I think sometimes there is a fear of, I need to make my test perfect. And so you never quite get around to it or you don't do it as often as you should do.

So I take the average of, I don't mind doing rubbish testing as long as I do a lot of it, and that I'm aware of any biases that are associated with it. I tend to avoid telling anyone I'm gonna do testing, because immediately they start interfering with it and if you ask management, they're gonna have opinions about it and maybe they say we don't have time.

So I tend to do testing below the radar, and I keep it very lightweight and very inexpensive. That's how I do it. One of the big problems with testing is always recruitment, finding people to actually do testing with. So when I'm testing usability, I don't always bother with the exact audience.

I'm quite happy to test with friends and family, anyone outside of the organization, anybody who is not associated with the project or anything like that. With usability, the only thing you need to bear in mind is the people you test with needs to have comparable levels of physical and cognitive ability.

So if you're aiming at a children audience or the elderly audience, then you probably need to test with children or the elderly. But for everybody in between, you're probably with usability fairly safe just to test with anybody. That's not to say it's always preferable to test with your target audience, but if you can't get hold of them, then it's better than nothing.

However, please do not ever test with anyone related to the company or the project, they're gonna have a degree of understanding that end users wouldn't have. And these days, many testing tools will recruit participants for you often as little as a dollar a person. So it really isn't that much.

I mean, there's a tool that I use called Askable that you can recruit people via Askable and get them to test anything you want. It's completely platform agnostic. So whether you're using figma or anything else, it doesn't care. And I think I paid 1 pounds 20 per user.

I don't know what that is in dollars these days, maybe a couple of dollars, something like that. So if you're testing with just a few people, you can pay that out of your own pocket, really, so yeah. I mean, there's there's so many testing methodologies that you can use and so many research methodologies.

It can be quite overwhelming, and so don't get too worried about it, don't get too hung up on about it. I'll share with you the kind of testing that I do a lot of. But if you wanna give something a go, then means have a go at it, see what happens.

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