Self-Descriptiveness (ISO 9241)

Self-descriptiveness requires that the system describes itself. It is closely related to understandability and one approach to making an application easier to understand.

See also Understanding, Learning and Relearning for more information and examples on this topic.

Why Self-Descriptiveness?

Self-descriptiveness provides simplicity by reducing users' memory load. Users can retain their capacity for their tasks instead of bothering with the system. They can work more efficiently.

How You Can Achieve Self-Descriptiveness

An application can be self-descriptive in a number of ways, for example:

The application is so simple, the task and its procedures are so well known (or well-trained) that no further explanation is necessary.
The application explains itself through cues, such as instructions or diagrams, which are presented on the screen or by using metaphors.
Explanations (more or less extensive) are available on request.

Help on Request

F1 help, F4 help, and extended help (online documentation) in the R/3 system are examples of help that is provided on the users' request. Such kind of assistance has, however, severe limitations. For example, it forces users to become active, interferes with the task, and takes time and effort. Many users prefer to ask their colleagues instead of using such aids or reading documentation.

Software without Documentation? – On-screen Help or Instructions

Some authors demand that software should be usable without documentation and should be self-explanatory. For example, they embed their help or instructions (explanations, instructions, diagrams, flowcharts, and so on) within the application. Typically, the following instruction types are needed:

A general instruction describing what the application is about, for example, what its purpose is and what it accomplishes
Step-by-step instructions, if necessary, for accomplishing the basic tasks
Explanations for important fields or fields with complex dependencies, legends, etc.

Instructions can be provided in the form of text or graphics, depending on what is more useful. Often these instructions can be integrated into existing screen elements, such as group headers or field labels, by expanding these text elements and using a more natural style of language. Longer texts can be placed into text boxes above or beside the work area.

Diagrams are especially useful for more complex steps and can also indicate the current status of the user.

This approach, however, has its limitations:

It costs valuable screen space
Professional users may be disturbed by the instructions (thus, provide options to hide or circumvent the instructions)
Developers and documentation people must work closely together in order to design the screens or pages and the instruction texts

Affordances

The term "affordance" refers to the fact that certain interface elements have the ability to "speak" in an obvious way to the users that helps them to interact with the software. For example, buttons say "Click me!" to the users, indicating that there is some functionality that can be used. Utilizing affordances helps interface designers to do with less or no documentation (on-screen or off-screen) because the interface "speaks for itself."

Metaphors

Metaphors can also make an application self-explanatory because they allow users to transfer existing knowledge to the application.

New Approaches: Assistants and Agents

There are new developments under way, such as assistants and agents. While assistants are already used in a variety of scenarios, it is still unclear whether people like "automatic" assistance as is provided by agents. Assistants on the other hand, take the initiative away from the users and guide them. Not every user likes to be restricted in this way. In addition, in a Web environment that is inherently amodal and has no dialog windows, assistants cannot be strictly modal. Users may interrupt the procedure, move to other pages or applications, abort the wizard, and the like.

top