At some point, early in the development of an application, a prototype is usually created. Prototypes are useful for getting early feedback from the users, and to make user-interface problems more obvious. We used to call these prototypes ‘clays’, after the practice of the car industry of creating a facsimile made from clay to showcase the design of a new car design to the general management.
It takes a lot of care to make a good prototype; it must look convincing. The clay cars had to look so real as to make you believe that you could hop right into it and drive off. Drawings or wireframes just don’t serve as well because the observer cannot make that imaginative leap.
With data-driven applications, the verisimilitude includes the data. A prototype application should have data in it that is so close to real data that even the dullest, most literal-minded manager could look beyond the detail, to the important matters.
Read this article to understand the scenario. I was shocked it was the same conversation I’ve had with customers after using a high-resolution, “Data-Driven” prototype. I called the following conversation the “Dirty Ferrari Syndrome (DFS)”.
My beautiful data-driven prototype was the Ferrari. I showed the customer it could do 150 MPH and they said: “It’s dirty”. I told them about the fine leather interior and they said: It’s dirty” I told them while it looks a rough, if we clean it up and add a little polish it will be gorgeous. They said: “Call us back when it’s cleaned up”. I said we need your help, they said: “That’s not our job.”
In your efforts to make the prototype look as “Real” as possible you walk into the uncanny valley where folks think they are looking at the Real thing, no matter how many stamps shouting “PROTOTYPE” there are. I have reverted back to bare frameworks with data from characters in the movies. We will see how this works out.