Category list

Chapter 37 -- Keep Looking for Improvements

Chapter 37

Keep Looking for Improvements

User interface work is never done. After all, a program is never finished—it's just due. No matter how good your user interface is, you can always make it better. Even if your program is a huge success, there is always room for improvement. Creating great user interfaces is hard work and that means constant improvement.

Plan for the Next Release Now

If you want to release software in a reasonable time frame, you can't do everything in the first release. You will be exposed to all kinds of ideas and suggestions in the later stages of the development process and once the program is released. The sources of this information include the features and improvements you were not able to do before release, feedback from actual users, feedback from technical support, and feedback from product reviews. Start to gather this valuable information as early as you can, and plan for the next release now.

Get Feedback and Take It Seriously

You should actively try to get the best feedback you can. Try to talk to real users. Talk to your technical support team, and ask them to create a list of the most common problems and complaints. You can get feedback from other sources, such as user requests , newsgroups, and user surveys. If the feedback doesn't make sense, assume that either you don't fully understand it or that the person has trouble expressing his ideas. Don't be afraid to ask questions or discuss alternative approaches.

Take the feedback seriously and look for patterns. One user complaining about a feature doesn't necessarily imply that the feature is flawed. Research has shown that there is a 97 percent chance that at least one user will complain about every feature in a program, no matter how good it is. (Just kidding—there is no such research, but it is probably true.) But receiving several complaints about a feature is a clear sign of a problem. If you think a task is easy to do, yet users find it difficult, they are right and you are wrong. Always. Don't dismiss this feedback or try to defend the feature—just fix it.

Avoid the Second-System Effect

The problem of the second-system effect is best described by Frederick Brooks, who coined the term . He said, "An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill, embellishment after embellishment occur to him. These get stored away to be used ` next time.' Sooner or later the first system is finished, and the architect, with firm confidence and a demonstrated mastery of that class of systems, is ready to build a second system. This second is the most dangerous system a man ever designs. The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a 'big pile.'"

Use Restraint

Can the second-system effect be avoided? Ideally, you want to add power and functionality to your next release, but you also want to make the features easier to use. You can accomplish this goal by using more elegant user interface solutions, such as:

Making apparently dissimilar features similar, as was done with the Microsoft Windows Shell Namespace used by Windows Explorer. The Shell Namespace makes Control Panel, the Recycle Bin, Briefcase, and even Microsoft Internet Explorer look like files and folders.
Making features more visible and easier to find.
Using drag-and-drop functionality and other forms of direct manipulation.
Fixing or removing problematic features.
Simplifying interaction by using appropriate defaults.
Eliminating unnecessary dialog boxes and message boxes.
Making the program faster.
Providing better system integration.
Simplifying everything you can.

Another common problem with lack of restraint is to misuse new technology. Never add new user interface technology just because you can. Always have a reason.

I find it interesting to compare current versions of programs to previous versions. For example, in comparing Microsoft Word 97 to Word Version 6.0 (from 1993), I find the current version much more attractive and easier to use. The appearance is visually much cleaner. Although the current version is much more powerful, the screen layout and menu structure isn't more complicated. Unfortunately, this isn't always the case. You should try to make your user interfaces simpler over time, not more complex.

While it is possible to improve your program and avoid the second-system effect, don't expect it to be easy. You'll have to make many difficult trade-offs.