Preventing usability mismatch

Ockham’s razor

A main source of mental workload is the multitude of options and features that marketing love it add to the system specification. With many screen displays, users spend more time learning where to find the information they need. With many controls, users spend more time learning which control is relevant to which task. The basic means to reduce mental workload is to shave away all unnecessary features and options. This guideline, originally targeting scientific argumentation, is applicable also to engineering. Simple is better, because it is easier for the users to find the information and the controls they need for their task.

Simplicity

Complexity may be defined by the number of links between objects. In contrast with Ockham’s razor, which applies here to refer to objects, simplicity is about the relationships between objects. The second basic means to reduce mental workload is to remove unnecessary constrains, such as conditions and sequencing, to enable direct transition from intention to action. Combined with ockham’s razor, we have the well known KISS (Keep It Simple, Stupid) principle.

Information tunneling

Software programs implementing Service Oriented Architectures (SOA) enable the user to reach all privileged properties and methods (use cases) of all objects. However, users are often overwhelmed by such design. The example of production waste above demonstrates the problem of irrelevant information. Typically, at a given point of a given procedure, they need to view only few properties, and to access a single method. To reduce the mental workload of finding the properties and methods relevant to the particular procedure stage, we arrange the operational procedures according to scenarios. In a scenario based design, we present to the user only the information required for the task they chose to perform.

Apparent power

Many customers do not appreciate the benefits of simplicity or stupidity (http://www.joelonsoftware.com/items/2006/12/09.html ). They prefer systems that look complex over those that look simple, because they seem to be powerful (http://www.jnd.org/dn.mss/simplicity_is_highly.html ). We can see this trend in huge selections of complex watches in watch and jewelry shops.

Progressive disclosure

Interaction designers face a dilemma:

·         Users want power, features, and enough options to handle all of their special needs

·         Users want simplicity; they don't have time learn a profusion of features in enough depth to select the few that are optimal for their needs.

Progressive disclosure enables satisfying both of these conflicting requirements. The idea is that redundant or unimportant features should be visible, but should be clearly separated from the features which are most significant for the main user tasks. Progressive disclosure defers advanced or rarely used features to a secondary screen, making applications easier to learn and less error-prone. (http://www.useit.com/alertbox/progressive-disclosure.html). Initially, we show users only a few of the most important options. Then, we offer a larger set of specialized options upon request. Disclose these secondary features only if a user asks for them, meaning that most users can proceed with their tasks without worrying about this added complexity.

The legend of adaptive systems

Computer scientist who seek to reduce complexity, are often tempted to adapt the system behavior to the user’s activity. For example, the menus of certain MS-Office programs, which are overloaded with items, first show the items used most frequently, and then, after few seconds, the remaining menus. All experiments intended to show the benefits of this method failed. The explanation for these results is that after the users have learned a particular setup, they expect it to remain the same; otherwise they need to learn it over and over again. It is easier to learn the setup once, so that in subsequent operation the mental workload is dedicated to real tasks.

Types of usability mismatch

This article defines two types of operational faults involving usability mismatch:

  • Basic operational faults, when the user fails to follow operational procedures required in normal operation
  • Recovery faults, when the user fails to follow recovery procedures.