Testing doesn't have to begin after the code has been written. In this week's column, Jeff Patton resurrects the oldest and most overlooked development technique, which can be used to test a product before any piece of it materializes.
Bill, the business stakeholder, gets a pained look on his face. "Yes, this software looks great, but it really stinks to use."
As the lead developer looks on Laura, the business analyst, explains "Well you reviewed the user interface before we built it. We all agreed that it would work, right?"
Starting to sound frustrated Bill says "Yeah, I know I did. We all agreed it seemed OK, but now that I use it, there are some things that really need to change before we can go live."
If you're in Laura's shoe's it feels like you did all the right things. You designed the user interface collaboratively with the user. Everyone felt good about it. You built it, and with a little help from a good visual designer, it turned out sexier than you'd expected. Your testing department tested it thoroughly, and you know there are no bugs. So why do you have to go back now and fix it? There's one very important test you likely forgot.
Functional Testing Isn't Usability Testing
In most software projects we're concerned with building functionality as specified, then making sure it works as specified--without bugs. But software that doesn't blow up isn't the same as software that's well suited to the tasks that users need to perform. Usability testing attempts to verify that the product is suitable to task by measuring exactly that.
Given some test subjects and a list of the tasks that users need to perform, we might measure usability by asking each subject to attempt to perform those tasks. We'd measure the following:
- Completion rate: How many users completed the tasks?
- Performance: How quickly were users able to complete the tasks?
- Errors: How many errors or missteps did users make while completing the tasks?
Improving usability means increasing completion rate and performance while decreasing errors.
Often usability testing is neglected in software development because it's considered time consuming or expensive to perform. In perfect circumstances, software is tested in a usability lab: Finished software or a high-fidelity prototype is developed; appropriate test subjects are rounded up; a lab environment is set up with a camera and recording devices; and a facilitator helps guide users through completing tasks, while observers watch via camera or through one-way glass and take notes. This whole process takes days or weeks on top of the time it takes to build the working software or prototype to test. Assuming we know the risks of skipping usability testing, given the difficulty of "the perfect" approach to doing it, we might work hard to avoid doing it or to justify not needing it.
But wait, there's an easier way. One of the oldest and most overlooked development techniques is paper prototyping.
Building a Paper Prototype Is Simple
Start with a blank sheet of paper to use as your computer screen; 11" x 17", tabloid size works best. Get index cards, pencils, scissors, markers, transparency film, and--very necessary--repositionable, double-sided tape.
Sketch each component of your user interface on an index card or heavy cardstock, and cut it out. Stick it to your user interface using repositionable tape.
For lists, lined cardstock works well. If your list contains data and you can print it from a spreadsheet or some existing piece of software, do that, cut it out, and stick it on.
When you're done you'll have a componentized paper prototype, which is better than a plain old drawing on paper. I call it componentized because you can easily pull off each independent component, move it around, modify it, or replace it outright.
Usability Testing a Paper Prototype Is