So...what is usability testing all about? Usability testing, in its simplest form, is all about testing whether the design of your application meets the needs of the users from a UI perspective. This test will uncover if your design is simple and easy to use, if there are glaring errors that prevent the user from accomplishing their work or even the more subtle things that might make the user's job easier or harder. Whereas traditional software testing is used to determine if your application does what it is supposed to do with the data it is given, usability testing is concerned with whether the user can successfully get the data in (or out) in the first place.
Usability testing is quite often relegated to second class status as far as testing goes and many times it is left out of the design process entirely. This is a real shame, since this form is testing is really the most critical. By testing your UI, you'll have the opportunity to find the troublespots that will trip up your users before you let them start using it (i.e. roll it out to production). Remember, the sooner you can find and fix errors, the cheaper it will be. If you can do this before you even write a line of code, you'll be making significant progress in reducing costs and boosting quality. Best of all, you will improve user satisfaction by performing usability tests and this is perhaps the most important metric of all (unless you don't really care about them...in which case you should stop reading and go flick the server on and off several times ;-)
Usability tests can range from really high tech (think two-way mirrors, video cameras, fancy labs) to really simple (e.g. a user & developer meeting in a conference room). Most of is aren't lucky enough to work in a company with a dedicated usability group, so it will fall to us to conduct the tests. I advocate a fairly simple approach and I tend to keep my methodology fairly lightweight. If you try to get too process heavy in this stage, you run the risk of subconsciously making up reasons to skip it ("We don't have enough time!", "There are more important things to work on!"). For a typical Lotus Notes business application, I think you can get some pretty useful data with a handful of users, somewhere on the order of three to five people. Of course, the larger your app and the more users you can test, the better your data set will be. Use your best judgment here. You'll get better with practice.
Once you have some users on board, what do you test? To be effective and to allow you to make logical comparisons with the data sets, usability tests should be task-based. That is, your test users should have a predefined goal to accomplish within the application. By using a defined task, you are setting the boundaries and restricting the users' choices. This helps keep them from ambling around the app without a purpose.
During a usability test, your most important job as a developer is concentrated observation. You should be recording notes on all the action the user is taking as they are working on their task. Pay particular attention to times when the user pauses or looks puzzled. It is perfectly OK to question the user when they perform an action or when they seem confused. The whole purpose of this process is to find errors or difficult aspects of your UI and these notes will serve as the main data you will analyze. Don't be shy about drilling into the user's thought process and let them know that it's OK to be brutally honest. Yes, sometimes the truth hurts, but it's best to hear about likes and dislikes now rather than later.
One important note here: When you are performing a usability test, be sure you make the user feel comfortable and insure them that you are testing the application not their skills. When things go wrong or a user does something you didn't expect, first tell them that it is OK. After all, this is why they are helping you. Then, question them and find out why they did what they did. Some really interesting data usually comes out of the things that are broken or when users try to use elements in ways you did not expect.
In the next article, we'll explore the actual mechanics of the usability test. For now, let's just assume we conducted a test and we have several pages of notes covering the specific task we studied. What do we do now? Now, we pour through the notes and attempt to analyze them. Look for common patters or themes across the various users. You are trying to identify the elements of your application that are broken or that caused significant delays or user frustration. If you did a good job with soliciting the users' thoughts as they carried out their task, you most likely have a good idea of why a particular component didn't work for them or why they got frustrated. The trick now is to take all of this data and fix the troublespots. (You can look for the good things too. If users really liked the way you implemented a certain feature, make sure you find out why and use this knowledge in the future).
Besides fixing the obvious broken stuff, a usability test is valuable in exposing an inefficient or cumbersome UI. As a developer, it is very easy to overlook the complexity we sometimes build into an interface because we are so close to the design. The usability test gives us an opportunity to take a step back and see things through the eyes of our users. Personally, I found this to be very valuable in making me more empathetic about the applications I build. After conducting a few usability tests, you'll begin getting a really good sense for what users find simple and what is difficult or annoying for them. You can leverage this knowledge in your next design and I believe you'll find your skills around designing UIs will start to improve!
Usability testing is most effective when used in an iterative manner as part of your overall development process. Although doing a usability test at the very end of the dev cycle is still better than not doing it at all, the biggest benefit (saving time and money up-front) is lost. The best usability tests uncover the flaws before you enter the coding phase, which is why I find testing with a low-fidelity (i.e. paper) prototype such a powerful development trick.
Testing a low-fidelity prototype is really not much different than testing a real, working prototype. Instead of having a computer to interact with, the users will interact with the individual pieces of paper that represent the screens of your application. In a low-fi usability test, the user will utilize a pencil or pen as their input device, rather than a keyboard and mouse. Instead of a computer providing the necessary prompts and results, this will be carried out by a human participant playing the role of the computer. Other than these relatively minor differences, the end goal is the same...capture notes on the system usability so that you can fix bugs and simplify the UI. The big "bang for the buck" in low-fidelity testing is the fact that you haven't written any code yet, so changes are really easy and really cheap. To redesign an entire screen requires no more than grabbing another sheet of paper and your markers! After you go through two or three iterations of your design and test cycle, you will have a great blueprint for how the application will work and increased clarity on how to move forward (no more staring at a blank screen wondering, "Where do I begin?"). Best of all, you're much more likely to deliver an application that your users will love to work with right out of the gate.
So now you've got an idea about what usability testing is and why you might do it. I hope that you see it is really just a logical component of good UI design and that it can allow you to produce a higher quality product than you might otherwise deliver. Next time, we'll look at some of the specific techniques involved in usability testing. I think you'll find them very simple to do while yielding very important results.
*No actual guarantee is implied, inferred, suggested, etc., etc. You're on your own here, pal! ;-)