I ran into a design situation recently which exemplifies a common problem with software design and usability. In actual fact, I'm exagerating some of the details and the overall design has gone in a different direction. Still, I thought this point was worth extracting and simplifying in order to make a general point.
We had a command line utility (yes, command line utilities have interfaces (the "I" in CLI is interface) that can benefit from HCI design) which did some general purpose work. Let's say it could set some properties on something. It was something like this:
myutility set \-p myproperty=myvalue \-p myprop=myval ...
One of the properties actually didn't work very well with this interface scheme. Let's say if you specified the property it would have to ask for confirmation because it was a very destructive thing to change. One reaction to this was to say "well, this whole interface is no good. We should do something completely different."
This often happens with software. There's some special situation which doesn't fit the general rule very well, and this forces an overall change in the interface design. Sometimes this makes the interface more complex Perhaps in this case it would have resulted in a separate utility for each property setting, so that the special property could be handled in a more predictable way. Maybe something like:
setmyproperty myvalue
setmyprop myval
...
In this case, having the utility come back with "Are you sure you want to do that" would not be such a big deal (like "rm \-i"). Also, these utilities are now very consistent with one another. But, perhaps you can also see the loss involved in this interface. Where before there was one utility to learn and remember, with one man page which is pretty easy to scan through and one \--help output, now you have a bunch of utilities, either many man pages or one clustered one, and non-shared \--help output. It is probably less easy to use.
This relates back to my post a couple weeks ago about differences in design heuristics. For a coder, this is a clear win. The architecture is very consistent and the rules are easy to state. It must be easier to use!
Yet, most users never come close to understanding the architecture of the software they use. It is too complex and they don't spend a lot of time using any individual piece of software. So what is an improvement for the developer is invisible to the user. And, in this example case, the usability of the interface has gotten worse.
Another alternative might be:
myutility set-destructive-property newvalue
myutility set \-p myproperty=myvalue -p myprop=myval ...
This is not a beautiful bit of architecture. It makes the developer in me unhappy. But, it is probably a better user experience (one man page, one bit of --help output, one utility to remember), and people are remarkably able to deal with special cases if in some way it makes sense in their flow of using the computer.
So, my general point is: Be careful of making big changes to your interface to accommodate small special cases. Often those big changes create a less usable interface than creating a generally easy to use interface with a special case interface in it.