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.

This isn't easy, as I have found to my cost in the past. I was once demonstrating a prototype application to a group of managers at a manufacturing plant. It looked the part, and the managers stared in awe at the screen, as if hypnotized. Some were fascinated to see how all those tedious and inaccurate manual processes could be so easily eliminated.

"It is a great application. When can we have it?" one of them asked, suddenly.

I smiled indulgently. "I'm glad you like it, but of course this merely demonstrates how the application would appear, once we'd spent all the necessary months of work to turn the prototype into reality"

He turned glum, and scowled, brooding on the slowness of IT in "finishing anything off". I continued with the demonstration and it was going pretty well, when one of the quietest of the managers suddenly interjected.

"No, there is something really wrong here!"

There was a ghastly pause.

"In that previous screen, you showed a message from the superintendent saying that we were running short of tuning relays. And yet, in this screen, that fact hasn't been ratified by the plant manager to turn into an order!"

It seemed that some were struggling to understand the nature of my mysterious conjuring trick. "Well, as I say, this is a prototype. It only illustrates the processes and the way we envisage the user-interface!"

A frisson of diffuse anxiety ran through the ranks of the audience. Having captured his audience, the guy was unstoppable.

"…and we just don't handle flexible grommets that way either, on a production line, because these are sourced from another part of the company!"

"Quite; there are many details to tidy up, and processes to analyze, which is why we are facing several months work"

"Well why didn't you find them out first before you showed us this?!"

It was the fury and disbelief of hearing that Santa isn't real. I lost the audience. After this outburst, several others felt impelled to point out that they too had noticed irrelevant inconsistencies in the mock data.

I am not sure what the moral of the story is, beyond stating that prototype applications need the same care as prototype cars, or mobile phones, in getting as close as possible to reality. You can't use real data, but the care you take with making it convincing will enable you to survive a brush with even the most literal minded manager.

Phil Factor.