User testing before you user test

In order for James Dyson to perfect his bagless vacuum cleaner he had to create 5,127 prototypes. That was in 1978, before it was free to code up something quickly and hand it to a user for testing.

Imagine creating 5,127 prototypes for your mobile app. This might be overkill, but user testing early on will save you time and money. The key to building a well-rounded project is to invest time early on to identify information architecture and user-experience gaps.

Consider the word: use. We create user stories. We want to build useful apps. We’re user experience designers. We use apps and we make products to be used. There’s a lot of responsibility that comes with this. After all, you cannot build a successful product unless it gets used in the early stages of creation. We call this user testing.

User testing has traditionally been focused on your target audience user group, but other groups can provide valuable, unique insights early in the prototyping phase.

When user testing a product, it’s crucial to understand what’s working, what isn’t, and why. If you work in a bubble, you’re often too close to the work, and you are likely building a product that is designed around your preferences, workflow and biases. That’s why it’s important to get insight on the product from different perspectives. You might be surprised by how the feedback improves the product. Maybe the hero of your project is actually the villain. Your users will soon let you know.

I like to test with three different types of users at the beginning stages of a product. But first, I set up a loose structure for testing.

User testing with a direct objective

Before I begin testing with different user groups, I establish a series of tasks, but make sure they’re malleable. For any user, it is important that you can adapt to their responses and be willing to go off the beaten path from your tasks. In the early stages of prototyping, it can be a good thing if users can’t complete their tasks; you’ll be able to fix user experience issues early on before you’ve invested too much time.

Besides the obvious users — the ones who will probably be using your product — I’ve found that it’s beneficial to begin testing in the early stages with a few groups of people who will probably never use your product. Let me introduce the friend, the peer, and the stranger.

1. Hi, friend — leveraging the personal relationship

Your friends will be willing to test your prototypes, and they may help you to find those UI holes. What I’ve found when showing a prototype to a friend is more often than not I get an honest and open response. There’s also a downside: the response is often sugarcoated.

I find the best time to test with friends is early on in the process. Friend testing is mellow, easygoing, and can help you to identify and iron out obvious issues right away.

Hang out, and observe first-hand

My experience is that friends are usually the most relaxed when testing, and they will talk about what they think throughout most of the process. That’s why I like to be present in the room when I’m testing with friends. I’ve found that observing how they navigate a product or a site is important, but so is answering a few of their questions.

Since you personally know the person who is looking at your product, I wouldn’t suggest using any programs that record them testing it.

After testing with the friend, you’re ready to apply the feedback to your product and begin testing with the next group.

2. Peers — getting input from the ranks

A peer is somebody, ideally, whose technical knowledge you respect. You like the work they do and have regard for their opinion. They, in turn, understand what you want to accomplish on a technical level. And while the feedback you receive will probably tear a few holes in your product, it can help you produce a more efficient and well-rounded product in the end.

When testing with a peer, expect to be surprised. Make it clear that anything goes and feedback is welcome, but establish the kinds of feedback you are looking for. Setting parameters for the feedback will help peers focus on the important things rather than the things you already know. Let your peers know they can break your product — it’s a prototype.

Too much of a good thing

There are a couple of caveats: keep in mind that your peers’ technical knowledge may be more advanced than your intended users. Peers will make assumptions and leaps your intended users may miss.

Another thing to watch out for: your peers may be too informed. For instance, a peer may provide you with fantastic guru-level critiques, but the biggest thing to look out for is that he may already know how to use the technology. Design patterns are subconscious. If you’re building a mobile app and you want use “sliding the finger across a page” to close a pop-up, your peer will probably make the assumption, but 65-year old Betty who’ll be using your product may not.

Test twice

Open the door and your mind to new opportunities with the product and see if there aren’t better ways to accomplish specific interface issues you’ve experienced. If you have time, test twice with peers: once from the early-on stage with the feedback provided from the friend, and last after you’ve incorporated their feedback and cleaned up some of the design/UX.

After you apply the feedback you like from your peers, your product should start to show some form. You’ll be ready for the main, big bang of your prototype testing: strangers.

3. Do talk to strangers — a lot

Strangers are at the top of the testing chain. They’re the ones who might cut the real holes in your user interface. There are more than seven billion people in the world, so finding some potential user testers who do not know of you or your product intentions shouldn’t be too hard. However, finding a stranger who is willing to spend time testing your prototype is a different story.

You’ll want to determine how many of users you’ll need for testing. If the number is large (more than 10), consider posting a link of your prototype to an online forum or a public user testing site. If you just need a few people, I’ve found going to a cafe with a charged laptop/phone and a few bucks is rather effective. Ask a stranger if they’d be willing to try out your prototype, and offer to buy them a coffee. If they have time, you have the perfect tester.

Provide structure — and space

When working with strangers, I’ve found the best approach is to give them some structure and then give them some space. Providing printed tasks is good so they have something to follow. Then sit back and just observe. As humans, we’re jam packed with emotions and whether or not we mean to, we can give off vibes or feelings with a hand gesture, look, etc. So with this group, I would suggest the less communication the better. Just let them do their thing.

The types of feedback to expect from these strangers could be anything: from you being completely shocked that they can’t find the menu to being completely shocked that you misspelled a word on the main page.

So the next time you’re in the beginning stages of a product, consider popping your bubble of product-development isolation. Put your early prototype in front of friends, peers, and even total strangers you’ve plied with free coffee, and see what they tell you. You may be surprised at the new insights, great ideas, and hidden problems you uncover.

In my experience, applying this early tester feedback puts you in better place to begin testing with your ideal user, and ultimately leads to a more polished, usable product. If you would like to hear about additional methods, please feel free to contact me.

Originally published at yellowpencil.com.