More on standard interfaces
In my biased opinion, one important consequence of who standard interfaces help is that if you are designing a system that people will be using a lot, one that they will regularly spend a lot of time with, please use a good interface for it no matter how non-standard it has to be. The drawbacks of a non-standard interface are more than made up by the benefits of a good one for the frequent users.
(I'm biased in this because some of the best programs I've used have had radically divergent and peculiar interfaces that were very well tuned for their jobs, and I want to see more of that sort of thing. And frankly it's sad and painful to routinely use a program that could have been so much better if only the designers had been willing to get out of their interface straitjacket.)
That said, a standard initial interface has an important advantage: the more standard your initial interface, the easier it is for people to get started with your program and thus get hooked on it enough to start learning the good stuff. However, this only works if people can do useful things with the initial interface, because otherwise the program's not too attractive in general.
The flipside of this issue is that if you are designing a system that will be used infrequently or casually, you really need to stick to the standard interface even if a different one would be better. All of which means that it is very important to identify your audience before you start designing things, and then check your assumptions (as you may find that usage patterns are different than what you expected).
(In this modern age of web-based systems, remember that different bits of your overall system may be used by different user groups. For example, consider an internal expense account/claim system; most people submitting claims will be doing so infrequently, but in a big enough organization the people going through and approving them will probably be doing this all the time.)
Comments on this page:Written on 25 June 2008.