>Interesting. How then does IBM's UCD model deal with the testing of sites >that are currently fully-functional? Does it assume that people criticize >it less because it is more "done"?
I think the principle at work here is that you need to implement and test a
prototype that is relevant to the type of feedback that you want to elicit.
In her book "Paper Prototyping", Carolyn Snyder classifies prototypes along
four dimensions (that are not mutually exclusive): Breadth, Depth, Look, and
- The breadth of a prototype denotes the amount of coverage of the final
feature- or content-set of the product that is represented in the prototype.
Broad prototypes attempt to cover everything; narrow prototypes only attempt
to cover a subset.
-The depth of a prototype denotes the amount of coverage within each
feature. Shallow prototypes only have sketchy details for each feature; deep
prototypes exhaustively prototype each feature.
-The look of a prototype denotes how close the visual treatment is to the
intended final product. Thinks sketches vs. fully polished UI.
-The interaction of a prototype denotes how close the interactions are to
the intended final product. This ranges from no interaction ('here's a
picture; whaddya think?) to simulated interaction (classic paper
prototyping) and on into the types of interaction afforded by various
After this long preamble, the point that is (quite correclty) being made is
that you will generally get feedback commensurate with where your prototype
is at each of these levels. In practice, this means that you will get more
high-level design feedback on a broad and shallow prototype than you would
on a broad and deep prototype. Test participants may percieve a prototype
with a fully honed look and set of interactions to be mostly complete and so
may focus their attention on the fine points of the design. If you've
already decided on your high level approach, this is entirely appropriate.