What is Really Necessary?

Tasks, Goals | Structure, Navigation | Functionality | Procedures (Number of Steps) | Data | Internal Structures | Interface (Screen Elements) | Terminology

Reduction is the "basic" principle of simplification! Here we discuss some possibilities for reduction.

Motto: No special wishes. More is less!

 

Tasks, Goals

Web applications should follow the rule "One task - application"!

Example: A typical question might be whether the tasks of changing prices and finding information about prices should be one or two applications.

 

Structure, Navigation

Reduce applications to as few screens as possible, and keep navigation at a minimum.

Example: Tabstrips reduce the number of, and avoid navigation between screens. Moreover, they help to preserve the context of the application.

Example: Be cautious with "rampant growth" of the application structure. Possible causes for this can be jumps to search screens or "trips" to related applications (e.g. for maintaining master data, such as customer data).

 

Functionality

Offer only the essential functionality (80/20 rule)! Offer this functionality in ways that users can easily find it.

Note: As easy Web transactions do not have menus, and can therefore only offer a limited number of functions, it is important to choose the functions wisely!

Example: Only the functionality that the catches the users' eyes is really used!

If there is less important functionality, hide it in order not to clutter the screen.

Note: Optimization means making the important things easier, and the less important things harder!

 

Procedures (Number of Steps)

Count the number of mouse clicks needed for a procedure! In most cases it is a good rule of thumb to assume that fewer clicks leads to easier procedures.

Web Guru Nielsen: In the Web users vote "with their feet (=Clicks)". A click too many, and the users will leave your Website!

Example: Dialog windows often disturb the flow of the processing. As easy web transactions do not have dialog windows, this lack of a feature is your chance for achieving smoother procedures!

 

Data

Complexity of data can be reduced with regard to

  • amount, structure and presentation

Example: Filters allow the reduction of the amount of data to be displayed.

The presentation for a data set can be more simple than the structure of it, especially if the amount of data is small.

Examples: A hierarchy often can be presented as an ordered list, e.g. a 5-level hierarchy of goods can be reduced to two levels or even one, if the number of goods is not too large.

Example: In case that data can be presented as a flat or two-level list , presentation with a tree control is not appropriate - even if everyone regards this as „cool"!

 

Internal Structures

Do not harm users with the complexities of the inner working of your application or its data structures!

Example: Do not require users to enter a group name for salespersons, if the company has only three salespersons.

 

Interface (Screen Elements)

Put only those interface elements on a screen or page that are really needed! This is especially true for fields.

Example: If users usually fill only three fields in a form, why display 30 fields that "might be needed" by some users? Often these three fields are "somewhere" in the middle of the screen and hard to find for users.

Example: Many users believe in the myth that, if there is a field on the screen, they have to fill it. So, help them by dropping unnecessary fields!

 

Terminology

Talk the users' language. Do not use abstract language or jargon.

Example: Users could not find the"parts list" in an application, because it was called differently.

Example: SAP uses its own terminology for many business terms. Users often do not understand these terms.

 

To top top

Source:  Simplifying for Usability