You probably aren't doing enough user testing. Testing feels like a chore, one requiring too much effort and taking too much time. User testing is often a difficult sell to program managers at the early stages of a project, something to be applied only to a nearly finished product as a means of adding polish.
User testing doesn't have to be this way. By testing at an early stage, we discover major problems before it's too late to fix them. With a quick and informal method, testing actually gets done.
To begin, determine a few tasks that will take a person around the product. On a website, this could be "Show me how to buy a T-shirt" or "how late is the business open today?" Stay general and conversational. Testing every detail of the product is not necessary. If testing navigation, create a task that will take people from a sub-page to another sub-page. See if they try a direct route, or go back to the home page.
I approach testing sessions as a conversation. Recording devices and formal scripts should be used, but aren't strictly required. If you're conducting quick and dirty testing, grab a person who doesn't look too busy and say hello. At this stage, finding someone with specialized industry knowledge isn't critical. The problems we're looking for are of a more basic nature that will appear with all users.
While maintaining an informal feel, I like to lay out a few ground rules at the beginning of a session. This primes your user to deliver useful feedback by putting them by at ease and getting them talking.
Begin with the premise:
I have some questions about a product that I'd like your feedback on. This will only take a few minutes, we can stop at any time if you like.
This communicates that the test isn't a big deal.
I'm trying to learn about this product and see if it's working well. This isn't a test of you.
This makes your motivations transparent and builds trust. Trust is important when providing criticism. People often laugh after the last line, as it breaks the tension.
I haven't worked on this project, so there are no hurt feelings if something doesn't work right.
The first part is helpful if it's true, but not worth lying about. If it is your own work being tested, find another way to to reassure that you'll be delighted to find problems, not hurt.
In return, please be honest and speak up if something is confusing or doesn't work the way you expected.
This makes the expectations clear and gives people permission to talk about problems.
This project isn't complete yet, and I know there are some rough edges. Let's concentrate on the way it works for now.
This eliminates distractions and further frames the kind of feedback you want to receive. If using a very rough medium like paper prototyping, explain the premise.
Finally, as you move through the product, please think out loud. For example, I'm not sure which button to press because...
This is the critical part. In addition to discovering problems, we can now understand why they are happening and gain insight on how to solve them.
Once again, putting the user at ease and in control.
With your user briefed, begin the first prepared task. Listen! Don't talk over them or interrupt. Watch and take notes, even as they struggle. Allow the awkward pauses to linger, as this is when the real insight to their thinking appears. Only give an answer if the person is becoming noticeably frustrated, and then acknowledge that the product isn't working well.
When the tasks are all complete, ask for any observations. This style of testing is not about how people feel, but about how the product works. That said, it’s important to invite users to say something they've been thinking about but aren't sure of. The responses may be useless, but can also be insightful.
Give your thanks and explain how helpful the session has been. Offer a little insight on your process by explaining your thinking. By letting a person in on your process, the experience can be more fun and insightful. This can help build support for more testing and will make test recruiting easier in the future.
If you have the resources, it's worthwhile to perform a formal, in depth test. If that isn't possible, this basic version of testing is the best alternative. The strength of quick and informal testing is that it makes basic problems apparent, so that by the time formal testing is conducted, the major issues have already been solved.
This method is simple and easy. It finds the major problems before it's too late to make big changes. It gets done.
For a more in depth look at the user testing process, I recommend Steve Krug's Book, Rocket Surgery Made Easy. In addition to user testing procedures, Krug covers how to sell user testing to stakeholders in the project. ■