Design Tidbits

back Tidbits Overview

Tools for Design and Visualization

Simplification

Interaction Design

Screen Design

Hierarchies

Visual Design

Design Process

Web, Web Applications, Web Design

Performance

Miscellany

 

 

Anti-Simplification – How to Make Life Harder for Users

By Gerd Waloszek, SAP AG, SAP User Experience – Updated: April 16, 2002

User interface designers strive to make applications simpler and easier to use. Simplification is a big issue these days, and feature growth is one of the challenges user interface designers have to fight against. So, why should I ask how we can make life harder for users – does that make any sense? Yes, I think it does. If we find out, which factors make applications more complex, we can learn – especially through bad examples that already exist – which pitfalls to avoid. In this article, I present such factors and illustrate them with examples. Most of the examples refer to business software, but many of them apply to form-based Web pages as well.

When looking for "trouble makers", I identified three factors – there may be more – helping developers to make life harder for users: (1) Unnecessarily increasing the complexity of applications, (2) disturbing users with technical and quality problems, and (3) "mindless" or "careless" design – we shall see below what this notion implies. Let's take a look at each of these factors.

 

Increasing Complexity

It is not difficult to increase the complexity of software applications; there are several ways how you can achieve that. For example, you can add obscure side paths to an originally simple application structure; value helps and searches are good examples for this practice. You can also replace simple controls by more complex ones with lots of functionality, toolbars and other gimmicks. Or you can add controls – or combinations of controls – which offer a dramatic increase of options or choices to the users. A fine trick is to play hide-and-seek with your users by implementing nested tabstrips or similar devices, which make work with your application more challenging. In addition, you can visually overload screens or pages either with a multitude of screen elements, such as fields or huge tables, or by adding decorative or distracting graphical elements. Here are some real-life examples.

Problem

Examples

Controls Are too Complex

Scrollable and Resizable Popup Calendar

Calendar control        Calendar control

Figure 1 and 2: Calendar controls of different complexity

Figure 1 shows a scrollable and resizable popup calendar, which is used as input help for date fields. This calendar looks confusing and is far too complex. A calendar for one month with scroll buttons, such as the one in Figure 2, would be more appropriate and easier to handle.

 

Too Many Choices - and no Structure

Giga Popup Menus

A long and hierarchical pop menu

Figure 3: A long and hierarchical pop menu

      

Many Microsoft Windows users may have a start menu similar to the one shown to the left on their computers. Users who manage to handle such a popup menu can at least be proud of their mouse skills.

This menu can be found on my computer. I must admit that I did not do much to achieve this state – I just installed some software, and this is what I got.

Start menus are, however, not the only complex popup menus – I found similar beasts in other software, for example, in business applications. Beside their size, popup menus also offer little structure and are thus hard to scan; this again is reason enough for keeping them small.

 

 

 

Information is Hidden in Deeply-Nested Structures

Nesting Tabstrips

Developers often believe that they serve the users of their applications if they provide everything that might be needed by some user some day. For example, an address may offer ten lines instead of the usual four; you can also enter ten more addresses instead of, say, two more. Assembling all the fields may mean that an application offers hundreds of fields where typical users might use, say, eight. The obvious way to handle this mass of data is to organize the many fields into groups and views. These views are then presented as tabstrips, which may contain dozens of tabs. So, when the number of tabs becomes a problem because space is limited, why not nest tabstrips? Instead of twelve tabs you can now have 12*12=144 tabs – isn't that wonderful? From a user's point of view it is not. Nesting tabstrips is a perfect way to hide information from the users. If a user does not know where a piece of information is located in the tabstrip universe, he or she has to scan the primary tabs as well as the secondary tabs when searching for this information. This may take quite a while. Therefore, the SAP R/3 Style Guide, for example, disallows nested tabstrips. However, there are "clever" tricks to circumvent such a restriction, as shown below. It may be too harsh to forbid nested tabstrips in general; there are natural groupings, which users easily understand so that nested tabstrips do not present a problem for them.

Now, let's show a trick how you can mimic a nested tabstrip: A set of buttons or a toolbar is equivalent to the tabs of a tabstrip. Therefore, you can use buttons or toolbars to simulate a tabstrip. This way a tabstrip inside this outer tabstrip is not that obvious. Figure 4 shows such a nested "pseudo-tabstrip". The three buttons below the two entry fields at the top form the outer tabstrip, while the inner level is provided by an actual tabstrip.

Nested pseudo-tabstrip

Figure 4: Nested "pseudo-tabstrip"

Nesting Group Boxes

The SAP R/3 Style Guide also discourages to nest group boxes, but does not explicitly forbid this. Therefore, nested group boxes can be found in the R/3 system.

Example for nested group boxes

Figure 5: Example of nested group boxes

However, when deciding in favor of this design option, be very careful and check other options as well. Nested group boxes make a screen visually more complex, because they add visual noise such as additional frame lines to the screen. Replace them by visually simpler solutions, such as white space or separator lines, whenever possible. You may use headings to identify subgroups if needed. In Figure 6 simple labels are used as headings; the hierarchy is indicated by indenting.

Alternative design using labels and indenting

Figure 6: Alternative design using labels and indenting

 

Technical and Quality Problems

How are technical and quality problems connected to simplification? Both make life harder for users. Technical problems typically slow down work, make interaction steps more cumbersome, or require a behavior contrary to common standards. They may not be easily overcome at the current state because any technology used, such as database or Web technology, has certain limitations. Some of the problems may vanish in the future, some may not. But this is outside the scope of developers and user interface designers. Quality problems, on the other hand, are simply annoying, because they should not be there. Below you find some examples of technical and quality problems.

Problem Area

Examples

Technical Problems

Long waiting times, annoying screen updates, extra clicks needed to activate screen elements, keyboard chain not or not fully supported, text truncated (e.g. as a result of technical shortcomings or translation).

Quality Problems

Improper alignment of fields or other screen elements, value help offered for fields where it does not make sense, buttons offered in toolbars for rarely used functions, buttons not disabled even though a function is temporarily unavailable, text not or only partially translated to the user's language.

 

Mindless or Careless Design

What is "mindless" or "careless" design? It is a design, which seems to be OK superficially and may even follow style guide rules, but it shows that developers did not really "use" their software. Otherwise they would have tried to get rid of the annoying "features" of their application. There may be many reasons for mindless design, such as time pressure, insensitivity to the users' needs, or technical restrictions. But whatever the reason may be, it makes the application more difficult to use. Thus, you can simplify your applications by avoiding mindless design.

Note that there is some overlap with quality problems - many of the designs in this category should not pass a quality check.

As you will learn from the examples below, contrary to intuition, a user's life can also be made harder by omitting or not providing certain features. Users have to overcome these deficiencies and support the system.

 

Problem

Examples

Important Functionality is Missing

Missing Select All/Deselect Functions

A multiple selection list without  a Select All/Deselect All function

Figure 7: A multiple selection list without a Select All/Deselect All function

Figure 7 shows an example where the lack of a certain function is annoying. A Select All function would allow users to quickly select all search criteria. The same is true for a Deselect All function.

 

User or System Input is not Used

Although the user already provided data or the system selected default data, these data have not been used by the system:

  • Example: An object list comes up empty on startup even though default values are provided.
  • Example: The user selected a person for a "mail-to" function; nevertheless, when the user opens this mailing function, an empty list comes up for entering the person the mail has to be sent to – the selected item is not shown in the list.

 

User Input is Thrown Away

There are many cases where user input is simply thrown away, although it might be useful for further interaction:

  • Filter settings are reset.
    Example: After a confirmation dialog all filter settings are reset.
  • Intermediate results are not saved – users have to reenter data
    Example: Description and notes for an object are not saved if the users switches between these two text types.
  • Settings are not stored permanently – users have to reenter them.
    Example: Layout settings are not stored permanently.

 

Spatial Relations Lead to Wrong Conclusions

The layout of a screen can be misleading so that users come to the wrong conclusions and do not know how to perform a certain action.

Example

The spatial arrangement of the function  incons may lead to wrong conclusions

Figure 8: The spatial arrangement of the function icons may lead to wrong conclusions

The spatial arrangement of the icons in Figure 8 may lead to the conclusion that the phone function acts on the first line, the mail function on the second, and the fax function on the third. Actually, users have to select a line and then click one of the three function buttons.

 

Missing Error Messages or Feedback

Most developers hate to implement error messages. There are so many situations to take care of, who will ever discover them all? However, simply let nothing happen if a user selects an improper function is not a good solution. The user may be puzzled and, for example, think that there is a problem with the application because nothing happens. He may then click the button again and again, until he gives up. Or he may think that he committed an error, but does not know what was wrong. Leaving users in a state of confusion does not comply with the notion of an easy-to-use application.

 

Conclusions

This article could have been much longer – the software universe is full of negative examples that are unnecessarily complex. Thus, you will surely find many more applications and Websites, which make life hard for users. But I sincerely hope that this article is a step towards easier-to-use applications and Websites. You as a user interface designer or as an application developer, in whichever company you may be, can play an active role in this movement.

 

References

 

top top