Reduction

Reduction is the principle closest to simplification. It means that you work out what is really essential for your software and what is not and can be left out.

See also What is Really Necessary? for more information and examples on this topic.

Why Reduction?

Reducing the complexity of an application reduces the users' work load, their working memory load, and leads to faster performance with fewer errors.

How You Can Apply Reduction

Reduction is applicable to all aspects of application design:

Reducing the goals (coarse-grain functionality)
Reducing the structural complexity
Reducing the navigational complexity
Reducing the functionality (fine-grain functionality)
Reducing the procedural complexity (number of steps)
Reducing the interface (screen) complexity
Reducing the terminological complexity

These aspects are not independent of each other. For instance, reducing the structural complexity should usually also reduce the navigational complexity.

Reducing Goal Complexity

You can apply the principle of reduction at all stages of the development. However, the key stage for reduction is when you determine the design goals for your application. Methods, such as task analysis, help you to determine the essential goals for your application and to avoid future complexity.

Reducing Structural and Navigational Complexity

After the basic goals of an application have been determined, you translate your abstract application model into a prototype with actual interface elements. This process may, for example, proceed via use case models that are procedures to use context models that contain screens and generalized interface elements to a prototype with real-world interface elements.

In this transition, it is useful to sketch a model of the application and navigation structure in order to keep track of the complexity of these structures. Graphical methods, may it be paper and pencil or graphic tools, assists you in this effort. Do not trust your own mental model. With an application growing and growing, this model will become more and more incomplete and complex. Do not expect users to understand such a model.

Reducing Functional Complexity

Functional complexity results from feature overload, bad structuring of functionality, or unclear goals for an application. Functional complexity can be reduced by focusing on the essential goals of an application and by leaving unimportant features out.

Web, Dialog Windows, Wizards: In-place Functionality

Sometimes, functional complexity has to be reduced for technical reasons. For example, on a Web page, in a dialog window, or in a wizard window, there are no menus. Each function has to be provided through pushbuttons on the screen (in-place functionality). This restriction automatically enforces a reduction to the essential functions. Do not try to "smuggle in" functional complexity through the back door.

Reducing Procedural Complexity – Counting Steps

Reduction is also important at a microscopic level, that is, with regard the actual steps users must take. Count the steps in a procedure, compare alternative solutions if there are too many steps, and choose the fastest solution (this may not be the one with the least steps). Each delay caused by an additional dialog window, confirmation button, etc. is a nuisance to the users!

Note, however, that there are exceptions to this rule. Users often find it easier to use a small set of commands and use simple commands repeatedly. They prefer this to learning additional commands that accomplish more complex and powerful steps. Usually, this phenomenon relates to the frequency of command usage.

Reducing Interface Complexity

Interface complexity often results from feature overload. For example, users are required to fill in fields that are never used in their work context. So, the above-mentioned reductions also help to reduce interface complexity.

Another source of interface complexity results from bad screen design. Fields may be misaligned, not arranged in the order of the work process, scattered over the screen, and so on. We do not want to go into detail here but would like to remind you of the importance of screen design. This issue is much more important on the Web. An HTML page has no grid and provides more options for arranging elements on a screen – and also more ways to do it wrong.

Reducing Terminological Complexity

Although many developers do not pay much attention to terminology, the terms that appear on a screen play an important role as to whether users will be able to carry out their tasks or not. Possible problems are:

The same object or function is named differently in different parts of your application
Different objects or functions use the same term
Your application uses terms that are not familiar to the user and / or the work context

Some developers like to invent their own terminology. However, usability guidelines (ISO 9241) require that an application speaks the user's language, not the developer's.

top