One of the ongoing struggles in the computer world is the quest for the “intuitive” interface.
There are consultants who make big money helping software developers create interfaces to their software which might conceivably be understood by the mere mortals who seek to operate it. Personally, I’m a big fan of Alan Cooper, who pointed out that the need not to look stupid really belongs at a foundational spot in Maslow’s hierarchy. For this reason, Cooper maintains, attention to user interface should be at the heart of software development, rather than an afterthought once the feature set has been built.
Great strides have been made in user-friendliness since the days when the user interface was a punch card or paper tape. I’d argue that much of that progress rests on the concurrent training of the computer-using public to recognize interface elements which were at first utterly foreign.
Consider, for example, the toolbar above. Every school kid knows what that does. But it was utterly new not so very long ago, and required people not only to learn the meaning of the symbols on the buttons, but also to master new skills of “highlighting” text with a mouse cursor.
Brevity, we know, is the soul of wit. A clean, intuitive interface makes a user’s heart sing (or at least prevents it from suffering palpitations!) The increased computer literacy of the public means that there is a much greater array of metaphors for which there is shared understanding than has ever been the case before.
But if software does something new, odds are the folks behind it had to develop new vocabulary and new metaphors to describe its use. Your users will have to learn what these new terms mean, and how the functions they refer to work. And the people who configure the software to customize it for different user groups will have to learn how to twiddle the knobs which control their function.
Just as it takes more time to write a brief piece than it does to write a rambling one, the development of a comprehensive feature set and the flexibility to configure the software “tightly” (to display the only features needed for each set of end-users) requires a lot of time. Even when the actual creation process has been highly automated, just learning how to operate the buttons and levers “behind the curtain” to configure that interface likewise requires a significant investment of time and effort.
Which is to say, that as we marvel at the intuitive interfaces with which we are increasingly presented in the banquet of Web 2.0 applications made available to us as end-users, we need to remain cognizant of the hidden work behind them. Not only is somebody writing the software, but somebody is configuring it and somebody is maintaining the infrastructure: The physical server, the operating system, the web server, the application itself all require the tender ministrations of either one extremely technical adept individual, or, increasingly, a team of them.
Adding new functionality to an organization always comes at a cost. Choosing to go ASP, and paying the vendor of the software to cover the hosting and maintenance can be a good bet. It may also be possible to contract with the vendor to do much of the configuration work. But odds are, you’ll also need to designate at least one individual in your own organization to be the “savant” who knows what the software does, what configurations are possible, and how to get the necessary configurations taken care of. And it’s quite possible that the simpler the end-user interface is, the more technically adept your configuration person will need to be in order to be able to create that “utterly intuitive” experience for your end-users.