In my day job I plan, recruit for, facilitate and report on usability testing. The kinds of tests I’m focused on are quick, low cost tests designed to discover the usability issues real people have when using your design.

The best advice I can give anyone who thinks they could benefit from usability testing is to just start. Get some people together and observe them using your design. Get others in your team to join your. The things you’ll learn from this first taste will make you eager for more.

Although straight-up observation will throw up many low hanging issues in your design, it’s worth learning a few straightforward tricks to make the most of your effort. With a little bit of planning and preparation you’ll be able learn more from your tests and be more confident about presenting your results to others.

In this 3 part series I’ll look at some steps you can include in your own pre-test preparation.

• Part one, Getting it RITE
• Part two, The test plan
• Part three, Recruitment and screening

Getting it RITE

Depending on what you’re testing you’ll need to choose an appropiate testing methodology. Just getting people in front of your design is a great start and you will learn a lot from the observations. But if you keep seeing participant after participant come up against the same blocking issue (like 60% of them not being able to login) you’ll not be learning much about what comes afterwards.

The RITE method (PDF), developed at Microsoft game studios, involves removing as many of these blocking issues as possible between testing days or even individual tests.

RITE stands for Rapid Iterative Testing and Evaluation. The general concept is that you observe your users performing tasks, taking note of any usability issues they encounter. You then categorise those issues into things that can be fixed now, things that can be fixed before the next test and complex issues that will need in depth design thinking to solve.

If possible you immediately fix the things that can you can, between tests, and continue testing the new iteration for the test of the participants. You’ll have removed as many of the simple gotchas as you can and with the rest of your participants learn more about the issues that may have been hiding behind those blockers.

In some cases RITE won’t work for you, for instance, if your application requires more than a couple of minutes to be compiled or you don’t have a developer on hand to iterate the code. RITE works really well if your testing simple paper or interactive prototypes that are straightforward to iterate and don’t need deployed on complex server infrastructures.

If you can’t use the RITE methodology you can emulate the process by first running a test with people from within your own company before bringing in recruits who are being compensated financially. You can then split you recruits up over a number of days and work on blocking issues between the sessions.

We’ve jumped ahead of ourselves here, but when you know what kind of testing you want to do you’ll be able to write your all important test plan.

In part two we’ll look at the basic structure of a test plan. Why you should write one, what it should include and how to put it into action.