Usability Levels – Three Ways to Care for Usability
By Gerd Waloszek, SAP AG, Product Design Center – 03/30/2001You can care for usability in a number of ways. The process of ensuring usable applications can be performed on different levels, and each level plays its part in developing usable applications. Nevertheless, in this article I'm arguing that there is one level which is really at the "heart" of usability.
The "Technical" Level
The technical level always played an important role in the work of SAP's usability group, now called Usability Engineering Center (UEC). This focus on technique reflects the fact that SAP has two development areas: The ABAP and Workbench groups continually care for SAP’s development tools and programming language. The application developers, on the other hand, care for the applications that are shipped to the users.
When working on the technical level, members of the UEC take care that from release to release the development tools offer new user interface features to application designers. These features have to be specified, put through and implemented. Due to the R/3 architecture this work has several facets: New data structures and ABAP statements have to be defined, the Development Workbench and the protocol between applications and presentation server have to be extended, and last but not least, the presentation servers, that is, the GUIs themselves have to be enhanced. This picture was valid for quite a number of years, but changed recently with the introduction of Web technology. Now, the development landscape has become more complex, as there are several technologies to consider and care for.
Thus, when working on the technical level, SAP’s usability people care for things such as the SAPGUI, certain technical features, Web technology, etc. For example, they check whether controls have been implemented according to the specifications and behave and look correctly when presented in the GUIs.
When doing this work a usability engineer needs a basic usability background, especially with respect to controls. So, he or she should be familiar with the style guides from Microsoft and other OS vendors. On the other hand, little or no application and domain knowledge at all is required. This often comes in handy, since it takes time to become an expert in application domains, such as human resources, controlling, or sales.
Usability work on the technical level is typically "proactive": It starts at the very beginning of a new release cycle and continues throughout the cycle. It also has to be one step ahead of the application development, thus giving the developers in the application departments the chance to use the new features in the next release.
The "Style Guide" Level
Usability can also be performed on the style guide or guideline level; synonymous names for this level could be "syntactic" or "structural" level because it is a more formal approach to usability. As with the technical level, usability people need little or no domain knowledge for this type of work. While application knowledge is useful, most consultations on this level - with respect to the purpose of an application - are fairly shallow.
When working on the style guide level, usability engineers look for conformity with guidelines and general usability principles. They typically use company-specific guidelines, such as the SAP R/3 Style Guide, not the more general OS-specific ones (there may be some overlap, though). During consultations, common issues are the correct use of controls, a correct menu structure and placement of menu items, the correct use of texts and terminology, a correct screen or page layout, a correct flow of control (left to right, top to bottom), and general principles, such as simplicity, efficiency, or conformity to the ISO usability norms.
This level of usability work is well suited to usability engineers when they start their career, as it requires little domain knowledge. While this may be regarded as an advantage for work carried out on this level, it also has its pitfalls, since we do not live in an ideal world: Release schedules are tight and, as a result, usability is still too often handled as an "afterthought". Thus, many usability consultations take place at a late stage in the development process. The only usability work that can be done then is on the style guide level - it is too late to implement major or even conceptual changes.
The "User-and-Task" Level
SAP's usability people always cared for the users' needs, but the Enjoy initiative and the influence from the outside consultants Cooper and Holtzblatt brought new impetus to a user-centered usability approach - a move, which affected the thinking of the whole company. This new thinking made it possible to restructure SAP's development process. A user-oriented design process was established, as is documented in many papers in the SAP Design Guild. But it's not only documented, in point of fact it has been brought to life. The basic idea is to involve users from the beginning of the development on, and to base the design on input from brainstorming and design sessions, site visits, user days, tests, and reviews. Prototyping plays an important role in this process. It allows to iterate fast and efficiently through design alternatives, and to let users play an active role in the design process.
Prototypical users, such as Cooper’s "personas" or roles, and scenarios, which describe how users perform their typical tasks, are two important elements of this approach. Questions one might ask on this level are: Who are the primary users of an application? Which are the main scenarios for a user, e.g. a secretary?
You may have noticed that I did not use terms, such as "controls" or "guidelines" in this section. Usability engineers following this approach also need technical knowledge because a design has to be implemented and finally cast into real screens or pages. But for a larger part of the development process, they are more in the role of moderators. They moderate between users and developers when conducting site visits; they also moderate meetings of the development team when they take part in brainstorming and design sessions. In the end, however, they need to know, which tools are at their disposal for implementing the interface, and which are the pros and cons of design alternatives and their technical limitations.
Contrary to the style guide level, work on this level does only make sense when usability is closely integrated into the design process - new applications and major redesign projects are the primary candidates for this approach.
Conclusions
All three levels of usability work are needed for developing usable applications. Technical prerequisites and style guides create the fundament on which usable applications can be built, but do not guarantee them. Only the "user-and-task" level ensures that a development team will really end up with a usable application that serves the needs of its users.
