The perils of appearing accurate

At work the other day, we were looking at a prototype of some software. The concern arose that, when we unveiled the prototype to the PTB (Powers That Be), they might get the wrong impression: if it looked too finished, they would take the demo UI too literally. At the very least the PTB could begin unnecessarily nitpicking... "rat-holing," in the common parlance.

Oddly, this misapprehension can occur with released products too. They look so darn good, so authoritative. In fact, most products out there will have some flaws, but the trick is to not let the consumer see them. Naturally this requires a bit of smoke and a couple of mirrors.

But the example of deceptive accuracy that sprang to mind as I was looking at our prototype was a set of IKEA assembly instructions. Now, by and large these are pretty decent, not least because they use little or no language, just illustrations, hence you get none of the infamous "Engrish". But the illustrations look very convincing. The number of screws is listed, there are helpful dotted lines showing where they go, and so on. They are of course too small to be really super-clear, but they do look pretty dang painstaking.

The key syllable, though, is "pain." Seldom have I assembled an IKEA item without at some point having to undo some or all of my work and attack it again — not necessarily because of human error (mine) but because some vital morsel of information has been left out, or is unclear. A screw may not have been drawn correctly. The number of screw holes drawn may not match the number of screws in my packet. In short, the seeming accuracy, the spiffy “fit and finish” product feature (in this case the manual rather than the object to be built) fools me into trusting it.

Now, there’s always the chance that I’m simply so anal that I fixate on the “perfection” or lack thereof, rather than just using my common sense and building the darn bookcase using the Occam’s Razor approach. But perhaps in some cases it is better to be vaguer in the implementation: "describing rather than prescribing" might be a way to think about it.