Week 7: Building and testing a web prototype

Summary

Having addressed the rigors of effective paper prototyping, Frick and Bohling now turn their attention to the need for a parallel exercise on the web that will show the limitations of the designer’s design plan – early in the process, to prevent a cascading of problems later on. “If we learn that what we have in mind just isn't going to work very well on the Web, then we can look at other alternatives before making too big an investment.” (p. 76)

They begin with a lengthy discussion of how the web, and web pages, work, and the available options for introducing interactivity, such as Java, Perl or PHP. Then they describe means of creating feedback, such as discussion boards and chats, that are outside the scope of our immediate class project.  But their treatment of student interaction with the computer is right up our alley: the use of multiple-choice responses and web forms. Finally, they discuss the use of templates (either custom-built or those provided by programs like Dreamweaver). Templates allow rapid prototyping and streamline production after usability testing.

The goal is to create a web prototype as rapidly as possible – with enough content to test the design but without every single part of the final product. The web prototype serves to test revisions that arose from the paper prototype, and reveal any problems with the web-based design. Like the paper prototype, it’s a process of discovery, and the process follows the same guidelines as the paper-based testing. Once the testing is done and the web prototype is revised, Frick and Bohling emphasize that the designer (or design team) faces a choice: whether to conduct another round of usability testing to test the revised product. They endorse choosing another round of testing: “If you still have problems with the Web prototype, and you go headlong into production, you'll just repeat the mistakes in the product and could end up spending more time and money fixing the mistakes later.” (p. 101)

Then, when the product is revised and finalized, they advise one more round of testing if at all possible. In Chapter 6, the authors provide an extensive guide to “bug testing,” the purpose of which is to “ensure that the product behaves as specified, without deviation from the design and without errors.” (p. 106) The steps are to decide the scope of the test, create a testing matrix, and conduct repeated cycles of testing (with documentation) and fixing – followed by “regression:” taking the fully tested and fixed product and working through the entire matrix again to ensure that every part behaves as it’s designed to.

Critique

I must confess to two basic reactions to these chapters. The first is that, whenever I encounter lengthy descriptions of web programs and their capabilities, my eyes glaze over quickly. I have to read repeatedly to comprehend, and often find my comprehension limited nonetheless. This stuff ties my brain in knots very quickly. The second is that, the longer I read (especially Chapter 6), the more I thought, “You’ve got to be kidding.” Perhaps in a perfect world, certainly in a university setting, but not in my workplace can I take the time to repeatedly test a product, or hope for a team with which to test it. As I suspect is the case in most settings, the designer/tester is a one-man band. What is realistic in my setting is to design the product, test it, revise it and then launch. Each user then becomes an iterative tester, and the product is debugged as it’s used. In my workplace, people will be quick to share the user experience, both good and bad, so one can count on feedback. Further, the product can be launched with the public caveat that it will be improved as needed – which implies the need for a feedback mechanism embedded within the product.

Lest I seem to be dismissing Frick and Bohling’s system, I am not. In fact, as with all things I see it paralleling the sort of advice I give to writers and try to follow myself. Once you’ve created a draft (a prototype), read it critically and/or find a trusted reader, then revise. Then read it critically again. And, if possible, again and again, in different settings and on both paper and computer screen to vary the user experience. Some people read their stuff aloud in an effort to find rough spots and errors. Whatever works. Even so, I recognize that for many people one draft and one revision is all they have time for before they must hand it off to an editor for a final read. That’s one reason why more than editor sees it before publication. So I find this system to be sound, as much as time permits. I simply think that any repeat testing before launch would have to be done by me, on my own time.