Usability testing for applications, interfaces or apps need not be a complicated, costly, or time-consuming exercise. There's a relatively quick and easy way to go about it -- and make all the needed adjustments that will keep end-users engaged and contented with the results.
That's the word from Steve Krug, a highly respected user-experience expert and author of Rocket Surgery Made Easy. In his recent keynote at MinneWebCon 2015, he suggests that DIY usability testing can be simple, inexpensive, fast, and effective.
Among Krug's suggestions are these eight key guidelines that pave the way for DIY usability testing:
1) Keep users talking and expressing their opinions. Working with users is often like therapy, Krug says: "The main thing is to keep them thinking out loud," he says. "You're trying to get them to narrate whats going through their head."
2) Keep the number of people you test small, Krug advises. The idea number of users at any one session is three, he points out. "With testing three users you're going to find more problems than you actually have resources to fix -- it doesn't take many users to find serious problems."
3) Keep things informal. A testing area can be set up anywhere in the organization. Plus, he adds, sharing the results of testing can be distilled into a single email, with bullets highlighting key issues discovered. "I don't believe in collecting stats, because you're only testing three people. No big honking report is needed, either -- it used to be a person who conducted usability reports would need to write a 30-to-50-page report with all kinds of screen shots."
4) Test early. When it comes to application development, "people wait to test until the thing was cooked, versus spending $5,000 on a round of usability testing while it was still in an ill-formed state," Krug says. "The problem is, if you wait until it's done, then it's too late to fix anything." Krug says testing can even begin with wireframes -- "the tests tend to be very short, bur you can get great insights,"
5) Test often. In addition, Krug advises, establish a regular testing date of once a month. "Once a month, bring in three people, and do testing on that day," says Shrug. "This simplifies testing by simplifying recruiting, because you know exactly when you're going to need people. It unhinges your test schedule from your development schedule." With testing tied too closely to development schedules, the testing sessions may slip if development milestones slip, he adds. With a regular fixed testing schedule, IT managers can test "whatever we have lying around at that time."
6) Get everyone involved in the testing process. The actual number of testing users should be limited -- three at a time -- but sessions should be open for observation and discussion by everyone across the enterprise. Making it a "shared experience can be incredibly powerful," he says. He also provides a helpful hint to make the event top of mind: have great food on hand. "The best way to get people to come to these things is to have the best snacks in the organization," he advises. Go to the best bakery and order those chocolate croissants.
7) Focus ruthlessly on a small number of the most important problems. "The problem with usability testing is very effective," Krug points out. "You can turn up a lot of problems very quickly. But it turns out that we do not have that much time, people and resources to fix usability issues. The problems you find always are more than the resources you have to fix problems." It's important to focus on the one or two key problems and funnel resources in that direction, he says.
8) Tweak, not redesign. "When fixing problems, always do the least you need to do," Krug says. "Don't go into and try to make it perfect -- go in and make the simplest change that you can," he explains. It's better to tweak than to attempt an expensive time-consuming redesign of the application or user interface. "Tweaks cost less -- tweaks don't ruin lives, break up families, wreck careers," Krug explains. "Small changes can be made sooner, and if you make larger changes, you're likely to break other things that are working fine in the process."