Making Software Prototypes

After you've written the tasks for testing your software, you are ready to make software mockups for your test subject to interact with.These mockups can take many different forms, from low-fidelity sketches, to paper prototypes, to software running on a computer. The mockup form which is appropriate for your test depends on where in the design process your software is. The newer a project or feature is, the more simple the mockups for testing it should be.

When to use a low-fidelity prototype

At the very beginning of a software project, extremely low-fidelity mockups are the most appropriate, because they are very easy to change.This allows you to try out a number of different designs before settling on one, and save you from wasting time by building unusable designs with code.

When to use a more complex paper prototype

Once you've determined what the basic shape of your software will be, it is time to test using more complex paper prototypes. To make a paper prototype, you must first decide which interface elements you need to present to your test subjects. With your tasks in hand, make a list for each task of all the possible menus, windows, and widgets that the user could interact with while she is trying to complete your tasks. This includes (at least the most common) widgets which would be shown if the user makes mistakes when trying to complete your tasks.

How to make reasonable paper prototypes

When I make paper protoypes for GNOME software, I generally use two tools: glade (an interface protoyping tool) and the gimp (and image processing tool). Using glade, I make mockups of the pieces of my software which I want to include in my test.Using the gimp, I take screenshots of my mockups and print them out.I also use the gimp to mockup widgets which are unsupported in glade. When all the required mockups have been printed, I cut them out, and label their blank sides. (During the test, the paper prototypes are presented to the test subject face-down during the test, and only revealed as necessary. Labeling their blank sides helps me to keep them organized.)

When to skip prototypes and use software in your test

Testing with actual software is appropriate for software which is mostly implemented. If you decide to test software which is actually running, there are some things you should keep in mind: 1) be sure that your tasks can all actually be accomplished using your software 2) be prepared to talk your user through the test if your software crashes or malfunctions during your test. Given that you want to interefere in the test as little as possible, it is best to run through your test a few times, with you playing the tester, to make sure that your tasks are accomplishable. This leads us to another ethical standard for usability testing: along the same lines as "Don't ask your tester to do anything you wouldn't want to do", is "Don't needlessly frustrate your tester".