Paper Prototyping and Setting Expectations During In-House Testing
This article by Jensen Harris describes some of the benefits of using paper prototypes for usability testing: generating testing material quickly and being able to gather user feedback early in the development process.
The article also references Carolyn Snyder’s book on paper prototyping (at amazon.com) which describes many more aspects of the method. One of the benefits that Snyder mentions is that nitpicky feedback can be avoided by using paper prototypes because they do not encourage users to think that the product is almost finished. (In a previous post I was also commenting on the dangers of using detailed prototypes.)
This particular issue may be especially relevant when you are doing in-house testing with participants recruited from the group of users that will later use the product. I once invested over one week into building an interactive prototype, assembling it from Photoshop screens, dynamic HTML pages including layers etc. (“Dynamic†in this case also referred to fine-tuning the screens over and over and pushing layers around until they were at the exact location I needed them in…) During testing, this could give the impression of interacting with the final implementation of the product, which ends up in the risk that “everybody’s going to think you’re almost done. And then when you spend the next year working ‘under the covers,’ so to speak, nobody will really see what you’re doing and they’ll think it’s nothing†as Joel Spolsky puts it in a post that is also referenced by Snyder. (This “working under the covers†does not only include the tasks of developers, but also those of user interface designers and interaction designers, by the way.) This may put your client, e.g. the in-house project manager, under internal pressure, when participants get the false impression that the product is near completion and also communicate this estimation to their colleagues. This may then introduce pressure for yourself as a consequence, even when you are completely on schedule, because it can be hard for a project manager to completely withstand this kind of influence from his peers or superiors.
When using paper prototypes is appropriate, this may also help giving users a more realistic impression of the phase of development the product is really in, which in turn avoids introducing pressures that have nothing to do with being behind schedule.
