- When to Stop Using Personas and Start Using People
- Performing Usability Tests
- Moving On
Performing Usability Tests
There are quite a few ways to perform usability tests, and they vary quite a bit in effectiveness and scope. Some testing methods take only a moment or two and offer general impulse reactions, while others take days and offer deep, rich insights that can only be achieved through extended use of a product. Following are descriptions of some of these testing methods, how they work, and what you can expect to get from each one.
The Browserless Self-Test
A sure-fire way to get some quick feedback on your site’s navigation method and information architecture is to test it yourself, using the browserless self-test. Browserless is my word for testing without the benefit of browser tools. All you need to do is hide the tools in your browser, so you can’t rely on Back and Forward buttons, the Address bar, the ability to refresh a page when something goes wrong, or bookmarks.
Each browser comes with a way to hide all its tools. And it’s such a bizarre feature that I can’t help but think it’s only there to give developers a way to perform browserless self-tests. (Why else would you be able to hide the navigation toolbar in a browser? The Back and Forward buttons and Address bar are the only tools that a browser has to offer.) The option to hide each of these tools is usually hidden in the View menu. Simply select the menu option to disable the various toolbars.
Once you’ve gone browserless, you can find out how good your navigation really is. Lay out a series of tasks to perform, such as "Purchase a rubber ducky" and "Apply for a job." Then run through each task to see if you can get around easily. You’ll quickly find that going browserless is a little like cutting off your right hand. You never realize how much you rely on the Back and Forward buttons until you lose them. Suddenly, you realize that in order to go back, you have to remember the name of the page you were on, be able to use a link to get it, and be confident that the link you click is the right one.
Finding a page within the site is easier to do if it has a clear, relevant title that maps directly to a link on the page you’re viewing now. If the link can’t use the exact page title of the page to which it links, it needs to at least instill enough confidence that users can tell they’ll go right to it by clicking the link. If the page cannot be linked to directly from every other page, users need to be able to eventually get to the page they want by following a logical path through the site.
For example, an About the Company page will probably be have a link in the persistent navigation on your site. Almost every page will contain this link and users can always find it. But a product information page about the rubber ducky you want to buy, on a site that sells thousands of different products, isn’t going to be so prevalent. To find the ducky, you need to be able to wade through the architecture of the entire site. You might start by doing a simple search using the site’s Search function. If the search results are good, you’ll find the ducky in no time. If not, or if there’s no Search box, or you’re not sure what keywords to use in your search, you might click the Products link, choose the Rubber Toys category link on the landing page, and then choose a particular rubber ducky from the category’s main catalog page.
What this means is that in addition to providing access to the products catalog, every page needs to be incredibly clear that the link leads to information about your products. Not information about the fact that you sell products, or how you sell them, or how you ship them, but a page that starts the process of drilling down into the site hierarchy to find the rubber ducky.
Using Target.com in a browserless test to locate a desk lamp, for example, I landed on a page full of desk lamps in two clicks by choosing Home Office from the Furniture drop-down menu in the persistent navigation, and then clicking Desk Lamps in the sidebar navigation on the landing page. Nice.
This could have been a lucky guess, however, so I tried another method. I chose Lighting from the Home drop-down menu in the persistent navigation and then clicked See All under the Desk Lamps category in the sidebar navigation—and ended up on the very same page. Still two clicks. Very nice.
Well done, Target.com. Someone there has probably used the browserless self-test.
Five-Second Usability Test
User Interface Engineering advocates the use of what they call the five-second test. This type of usability testing involves gathering some users, or going somewhere many people are likely to be gathered at once (they suggest the company’s cafeteria), so it’s slightly more complicated than browserless self-tests. The focus is very different, however, as this test is intended to yield insights about the clarity of a site.
To perform a five-second test, write a list of screens on your site or in your application that need to be particularly clear and concise, and either open them in different browser windows (or tabs within a single window) or print them out and bring them to the users. Show each user the screens, one at a time, for five seconds each, and ask the user to write down notes about everything he or she saw.
A prime candidate for a five-second test is a page that has only one purpose and is particularly important to the success of the site. For example, a page on a domain name registrar’s site that enables users to search for domain names—the key product for the company—should be crystal clear, because making the Search box difficult to find would adversely affect the company’s sales. Ask the user to look at the screen for five seconds and locate all possible extensions (.com, .net, and so on) that she can use with her new domain name. When the five seconds are up, have the user write down everything she remembers about the page. Ask her what she think is the focus of the page. Ask her what the domain extension options are. Ask her what she’d click to choose a domain extension.
If you get the answers you want, you’re doing well. If not, you should probably redesign the page. Don’t perform a major redesign on it, though, unless it’s really off the mark—just apply incremental changes to it until it works.
For more information on five-second tests, see the UIE’s detailed article.
A more complicated but also more in-depth approach to usability testing is to perform interview-style sessions. Typically, this testing requires between three and eight users and lasts several days, but you can reduce that number to two or three users with all the tests performed on a single morning.
Steve Krug, author of Don’t Make Me Think: A Common Sense Approach to Web Usability, recommends performing tests on a single morning and debriefing over lunch. The idea is that more people are likely to be able to attend some of the sessions if they’re scheduled in the morning, and lunch is just long enough to take the information you get and decide what to fix and when to fix it.
These types of sessions involve more planning than other tests. Prior to performing a usability session like this, you need to plan a set of tasks that users will be asked to complete, prepare a lab of some kind (a room in which to perform the tests where you can record the sessions—preferably on video), and schedule users to come to your location.
Preparing tasks to be tested can be time-consuming, because the ideal tasks are those that satisfy the key business objectives while also fitting in with a user’s goals. For example, a stock photography site might have a key business objective to establish a large base of repeat visitors, while a user’s goal might be to find a quicker way to get through the thousands of images available on the stock site. The application might enable a user to add any image she sees to a personal library so that, on future visits, she can go straight to a small set of images she already knows she likes. The tasks of creating and using the personal library are perfect for usability testing.
Getting a lab set up is a trick all its own. Some usability labs contain two-way mirrors so attendees can view sessions as they occur without interrupting those sessions. This type of setup usually requires video equipment of some kind so sessions can be recorded. This can all get expensive quickly, because you need a dedicated space for the lab, equipment, people to run the tests and serve as session moderators, and compensation for the users, each of whom will be stuck with you for one to two hours.
An alternative is to use a product like TechSmith’s Morae, which is three applications in one:
- Morae Recorder is installed on the computer to be used for testing. It records the screen during the session, as well as the user’s face, via a webcam. This audio and video is quite useful for review, because you can play the videos back picture-in-picture, so you can see exactly what the user is doing from close-up, while watching a larger view of what happened on the computer screen.
- Morae Remote Viewer allows the test moderator (or someone else) to watch the session from another computer as it occurs. Additional licenses can be purchased for this piece, so you could have several people watching a single session from the comfort of their own cubicles.
- Morae Manager is used to review the videos, make notes at various points within each one, create a highlight video to include with a formal usability report, and export screenshots of certain moments in the testing sessions that capture key issues or successes.
At around $1,200 per year, Morae is a bit expensive, but this cost includes all upgrades for the year, and it’s still significantly cheaper than setting up and maintaining a permanent usability lab.
Finding users to test is also sometimes tricky. Some people use marketing agencies to handle this phase, because such companies keep detailed profile information on hand and can simply pull up a list of people that fit the profile for the test session. Then they handle calling all those people and scheduling as many people as the company doing the testing needs. This approach has a cost, of course, but it can be a big time-saver if you’re busy doing other things. If you have a product support department within your company, however, you can try to leverage that fact by getting the support people to sign up and schedule testers. You might also add a link to your site that lets people know they can get involved in improving future versions of your product by volunteering for usability tests. This link should direct users to a screening survey on your site to help determine ahead of time who might be good for a particular testing session. You can leave this link up all the time, in fact, providing that you have a way to manage the pool of users that will be generated by it. Doing this, you can simply pull up a list any time you want to run a new test, make a few calls, and you’ve got a testing session.
Interview-style testing can have one major downside, in that users tend to open their "critical eye" while taking part of usability testing sessions, which can obscure the truth about the test results. Despite telling them you’re testing the software and not them, users tend to think that they need to be really thorough and mention every little thing they come across, which isn’t really how people work with applications in their own environments. Also, the fact that the testers are in a lab setting means that they won’t know certain information about the computer they’re using, such as bandwidth settings and what (fake) credit card number to use if they’ll be making a purchase as part of the test. This lack of information can throw off the tester and interrupt the testing session.
To avoid these issues, and possibly gain more honest feedback, you can try doing reconnaissance testing, which is less formal but possibly more natural. It involves watching users interact with your product without telling them that you’re taking mental notes about how it’s working. You can do this by asking people within your company to walk you through a certain task under the ruse that you don’t already know how to complete it, or simply walk over and strike up a conversation with someone using the product and ask what they’re up to. Of course, you run the risk that this person will stop working while you’re talking to him, and that isn’t any good. To prevent this problem, you could just eavesdrop from behind a nearby rubber tree plant. Pretend you’re reading something and just listen to the user complain to his neighbor about how difficult it is to find a rubber ducky on your site.