Every Monday morning for two years Ellen Smith received a computer printout 5-inches thick. She would spend the rest of the week correlating, labeling, and indexing the data. She had a few simple software tools to help her, but for the most part she read through and marked up hundreds of pages of data. Thursday afternoon Ellen would enter all of her work into the computer.

Early in my career I was given the task of analyzing Ellen's work flow to discover anything that could be done to streamline her work process. It didn't take long for us to discover a way to save two days worth of work by introducing a simple program which would filter and sort the data before it was printed out for her. I spoke with the developer who had written the program, and he was very willing to make the simple five line change in a PL/1 program. Ellen had been wasting two days a week for two years because the programmer didn't fully understand her work flow.

Fred Brooks, in The Mythical Man-Month, states that the purpose of software is to make the computer easier to use. Software developers often lose sight of this goal or simply may not know how to make the computer easier to use. Usability design and testing, performed before the software is developed, can significantly help a developer along the path of making software easy to use. In this post, we are going to focus on usability testing.

The primary goal of usability testing is to gather opinions and experiences from potential users, and use that information, to make design decisions with the user in mind. This is accomplished in four simple steps: choose the testers, evaluate the testers, perform the test, and summarize the findings.

Before a usability test can begin, the preliminary screen flow designs need to be completed. Information used to develop the initial design should come directly from a user population. Often it is difficult to free up a user's time to do requirements gathering, so another person may stand in as a user proxy. The initial screen designs can be developed by hand or with a tool as simple Balsamiq. When this preliminary work is complete, the usability test can begin.

Choose the Testers

The ideal tester is a person who will actually use the system. For example, friends can be used to test the design of an online store, but you will need a very different person to test a custom application for your company. A manager or user proxy may be able to give general direction, but the actual users are the source of the raw data you are looking for. Studies have shown that only a small number of people are needed for the tests to be effective (i.e. 3 to 10 users max.)

Evaluate the Testers

The screen flow testers should come from a potential user base. Confirm that each user has the appropriate background for the system you are testing. This can be done formally through a questionnaire, or informally by verbally asking a small set of questions. Software for a kiosk is very different from office workflow optimization software, and the testers should represent the appropriate user community.

Perform the Test

The goal of a usability test is to present the system design to a potential user and determine how easy it is for them to use. Try to find out if they would use such a system, what they like and don't like about the design, which design elements are clear or confusing, etc. Testing may even reveal system requirements that previous conversations had not discovered.

You don’t need a state-of-the-art usability lab with one way glass, video recording, and eye tracking software. You can gain a wealth of insight into a system by mocking up the screens and presenting them to the user in conversational form. Since your purpose is to elicit feedback on design elements such as the placement of buttons and data entry fields, your mockups can be fairly rough. I often use Balsamiq to mock up wire-frames of screens. These portray the general idea of the functionality without having to worry about making the system look nice or functional.

The general working outline of the test follows this pattern:

1. Introduce the system and assure the user that he or she is testing the design. The user is not being tested.
2. As you walk through the screens you have mocked up, be sure to ask questions about the design. Examples of good questions are: "what would you expect to happen next?", "would you expect to see that somewhere else?", and "what else might you be thinking when you use this screen?"
3. Upon concluding a series of screens, be sure to determine how easy the system is to use, if the user would be likely to use it in the future, and the areas he or she particularly liked and why, etc.

Summarize Findings

Summarize all your notes into a list of things to change in the system. Offer recommendations for each problem identified. Each system change should be noted in such a way that it can easily be implemented by an engineer. Things such as changing a label for a field are quite easy; changes in whole work flows may take a bit more work, but it is worth it. My experience is that when someone on the team employs even a small degree of usability testing before the system is built, usability survey scores come back very positive - scores over 80 out of a possible 100.

When the purpose of software is to facilitate human-machine teaming, the primary goal of usability testing is to gather opinions and experiences from potential users, and use that information, to make design decisions with the user in mind. Talk with people to ensure that you understand the human side of this equation as much as you understand the machine side.