[/caption]
“I have often thought that if photography were difficult, in the true sense of the term – meaning the creation of a simple photograph would entail as much time and effort as the production of a good watercolor or etching — there would be a vast improvement in the total output. The sheer ease with which we can produce a superficial image often leads to creative disaster.” – Ansel Adams
Ease of use is something which is highly desired. Industries are built around it. Intellectual property laws allow entrepreneurs to innovate to make almost anything easier to do. In the 1980′s and 1990′s companies would spend a great deal of time and money on business process (re)engineering. The end goal was to have processes and systems which were easier to perform and easier to use. While it was recognized that this would be expensive, the elusive “ease of use / ease to perform” was thought to be well worth it when all was said and done. The investment was seen to pay for itself handsomely through increased efficiencies and greater organizational effectiveness).
But here’s the rub. Once outside of the primary knowledge domain, the ease of use concept too frequently translates into “easy to do.” There are at least two aspects to this phenomenon. I characterize them as “how hard can it be?” – which is form of naivete in complexity, and “anyone can do that” – which is a form of naivete in skill set.
How hard can it be? Over the last few years products have come to market with exceptional user experiences. This is in large part to the confluence of recent technologies for execution of user interaction, tools to blend the design and development processes, and an increased emphasis on information architecture as it pertains to usability. A well designed user experience will give those using the system exactly what they need, when they need it – and nothing more. It will operate seamlessly in the operation of the process it is designed for. Most importantly, it will be extremely intuitive. Frequently this means hard fought for simplicity in core functions at the expense of functional abundance. Unfortunately it is this simplicity which leads people to think that it is exceptionally easy to deliver, irrespective of the amount of work in the user interface to arrive at the simplicity, nor the amount of work that has to happen through all layers of the application or system architecture. In short, the naive thinking is “This is great, how hard can it be to deliver? After lunch would be fine.”
Anyone can do that. This is very prevalent in the area of end user computing. Spreadsheets, for example, are used by virtually everyone in accounting and finance (and most other functional areas outside of core manufacturing). For the most part, everyone who can use a spreadsheet can author a spreadsheet. What frequently happens is that what starts out as a very successfully developed spreadsheet to perform a straight forward function somewhere its life crosses the line (largely due to its initial success as a single purpose spreadsheet) and becomes a software application which uses numerous formula which the author is not fluent in, perhaps has some visual basic for applications, pivot table, and charts, and imports data from other spreadsheets or third party services. No where in the spreadsheet development is a rigorous software development test performed (as it would be if it was developed by professional software engineers). [By the way, virtually every documented study shows greater than 90% of all spreadsheets contain errors - many of which are undetected and continually cause damage until the errors make the headlines. ] The notion is that it always has worked, so why wouldn’t it work now. The issue is the general sense that anyone can program spreadsheets as it is so easy to do so.
Access databases are similar, although there are fewer people who jump in with both feet, but it is easier for people to stretch a little beyond their capabilities in programming database queries. In the end, while it may be easy to do, you might end up with something different thatn you expected, headaches and all.
The take away here is three-fold. First, there is typically a high correlation between the system simplicity / intuitiveness and the difficulty in delivering this state. Second, not everyone can deliver this highly desired state – there are special skills required. Finally, be careful what you ask for when adding features and complexity, you might end up with a wolf in sheeps clothing.
