|User Productivity Worldwide – Branding, Design, Accessibility|
|SAP Innovates Usability Testing|
|SAP Developer Network|
By Jan Schulze, SAP INFO Online – November 19, 2004
German Version • This article has also been published on SAP INFO Online
For the last 15 years, the Usability Engineering Center at SAP has been making sure that the software is easy to use. It is the place where procedures are defined, user interface designer are trained, and many obstacles on the way towards an intuitive product are overcome.
Long-term SAP users will still remember the days of SAP R/2: A black screen on the 3270 terminal, which could only be operated by the initiated. While in those pioneering days of electronic data processing, the technology and its algorithms were the general focus of attention, the user has moved to the forefront in recent years. At SAP, this change was rung as early as 1989 with work on SAP R/3, and the Usability Engineering Center was founded. The department's aim is to make the SAP software as easy to use as possible.
"At the start, we were mainly concerned with writing style guides for the developers," says Ulrich Kreichgauer, manager of the Usability Engineering Center. Initially, fundamental issues needed to be clarified: In the world of SAP R/2, the function "write entry to the database" had many different names. Depending on the application, the developers called this procedure "Save", "Store", or "Write to database", for example. One of the first tasks of the usability experts was to create a common language that applied to all SAP applications. The Usability Engineering Center was also concerned with deciding where on the input screens the menus and fields should be positioned.
Figure 1: Development of the SAP GUI (click image for larger version)
The issue is not which colors or button shapes are used. "Attractiveness plays only a tiny role from a usability point of view," explains Kreichgauer. "Usability means offering something that supports a particular task as effectively as possible." As far as the usability expert is concerned, a product itself should ideally reveal everything about its use and make errors impossible. One clear example of this is a door sign: if a door needs to be pushed open, a simple door plate is the best solution. This can only be pushed, and thus makes it largely impossible to open the door incorrectly.
Figure 2: Ulrich Kreichgauer
The Usability Engineering Center has established itself as the central point of contact for usability issues. The experts do not just work on concrete software projects in exceptional cases, as Kreichgauer explains: "We define the procedures, processes, and methods used to ensure easy operation of the products. Application user interface designers from the development departments, who were trained by us, are responsible for putting this into practice in the projects."
Thus the Usability Engineering Center has drawn up a process for software development that ensures that user friendliness is taken into consideration from the very start, for example. Based on the motto "User Interface First", work on new solutions and releases starts with the question of how a user can complete a task in the most effective way. Here, the individual steps in a workflow are defined, the links between the individual steps are worked out, and where possible, tests are also carried out using prototypes. The GUI (graphical user interface) specifications are based on this. Ideally, programming work should not start until these steps have been completed. At the end of development, usability tests are carried out with users who volunteer for this.
There are good reasons for prioritizing usability, as Kreichgauer explains: "If usability is not tested until the end in our laboratory, disaster could strike. The test users may not be able to use the screens or solve the tasks they are set." If usability considerations come at the end of the development cycle, there is no longer any way of making extensive changes. "The usability tests prior to product delivery can only help with fine tuning," stresses Kreichgauer.
The importance of usability is generally accepted at SAP and is fully supported by management. This is reflected not least in the fact that usability is a fixed part of the "innovation lifecycles process" and usability is also assessed in quality assurance. However, the usability experts in Kreichgauer's team must always expect conflicts. "Often, users do not want something new, they want their familiar environment." When the SAP lists were changed from a gray to a white background, internal testers complained that the SAP white was brighter than the Microsoft white in Windows - even though both were exactly the same color.
For the design of applications, the usability experts must constantly weigh up the different requirements and reach compromises. From a usability point of view, it is preferable to have as much consistency as possible across all products, for example. However, in Kreichgauer's opinion, this misses the practical point of usability: "It is about how I can provide a user with a tool tailored as effectively as possible to his/her requirements and task, and which can be used intuitively." Even though the writing of entries to the database is now called "Save" in all SAP products, for example, there is one exception: In Accounting applications, this function is called "Post". An accountant posts rather than saves data, and this function name therefore increases usability in this particular area more effectively than if we were to insist on absolute consistency." A purely scientific approach to the evaluation of the GUIs is therefore not enough. To a large extent, Kreichgauer and his colleagues must also draw on their many years of experience. However, users always have the last word in matters of usability.
As the users and their work are the central criterion for the Usability Engineering Center, work in the field is absolutely essential for Kreichgauer: "The interface designers and developers must look at how users actually work in situ. We must be familiar with the users' tasks, so that we can provide them with the optimum support." There could be around 500 possible fields for material master data, for example, even though not all of them would ever be needed at the same time. "The difficulty lies in not displaying too much information, but also not displaying too little, and in making all the task-related information available."
Despite extensive efforts to continuously improve the usability of the software, SAP still has a poor reputation in this area, according to Kreichgauer. "However, at least 80 percent of the time, this is not due to the software that we deliver," states the usability manager. The problems users experience are more often due to poor customizing, a lack of user training, and customer-specific enhancements. "We naturally have no control over this," says Kreichgauer. "It is a similar problem to workplace ergonomics. We cannot tell whether a workplace equipped with our products meets workplace regulations. Many factors, determined by the user alone, play a role." For example, there is a standard that defines what an easily readable font should look like. "Whether the font appears on the screen as defined by the standard depends among other things on the user's monitor settings. We can only ensure that our software makes it possible to meet the regulations in each individual case."
Don Norman: "The Design of Everyday Things"
Anyone wanting to find out more on the subject of usability would be well advised to start with "The Design of Everyday Things" by Donald A. Norman. The author looks at how everyday objects are designed from a usability viewpoint. The book mixes anecdotes with theory, and practically no objects are spared. The English paperback edition (ISBN 0465067107) is available from bookshops.