I happened across my copy of “The Design of Everyday Things” the other day while I was helping a client specify how to add new functionality to their existing product.
As I browsed through some of the key sections of this book again, I got to thinking — What user interface (UI) characteristics are necessary when adding functionality to an existing product?
First, let’s establish a couple of obvious assumptions:
- Appropriate Functionality — We’ll assume that the new functionality actually addresses a real need or requirement. Otherwise, it wouldn’t (or shouldn’t) be added in the first place.
- Appropriate Performance — We’ll assume that the new functionality will perform about the same as the rest of the existing functionality. It wouldn’t make sense to add a new function that was extremely slower than the rest of the application because nobody would use it. And if you added new functionality that was extremely faster, the rest of the application would suffer by comparison.
Now, let’s define the necessary characteristics for the UI for our new functionality:
- Must Fit — The new functionality must” fit” into the existing product. In other words, users should not be able to tell where the existing functionality ends and the newly added functionality begins. So, even if the rest of the product has got a horribly ugly color scheme that you’ve been dying to change, don’t change it only for that new button that you just added.
- Intuitive — The new functionality must be intuitive to use. We often assume that our users are very sophisticated and understand completely every button, menu choice, and operation. Thus, we often don’t think twice about adding new functionality that only our most experienced users will understand (or appreciate). However, the goal should be to drive down the level of knowledge required to use our products so that more users, including those that only use our products infrequently, can benefit from the functionality that we are providing. Repeat after me: “If you have more users, you usually have more revenue, which is a good thing.”
- Multiple Paths — The new functionality must be accessible through multiple paths, or sequences of steps. We sometimes assume that all users will only use a particular function in a specific sequence. For example, we might assume that the user “Saves their work and then Exits”. So if the user decides to “Exit” first, should their latest work be lost? Of course not. We should detect that they have not saved their work and prompt them. This simple example illustrates the importance of allowing users to perform each new function in variety of ways and in a number of different sequences whenever it is possible.
Each of these characteristics seem pretty clear (and somewhat obvious) to me. So, why is it that too many of the software products that we use everyday continue to violate these fundamental concepts? Is it a question of laziness or do we simply lack the resources to do something right, so we band-aid something together quickly with the idea of fixing it later and “later” never comes? Or perhaps our users have gotten so used to applications that are clunky and difficult to use, that we don’t feel the need to give them anything better.
What do you think?