Introduction to User Interface Patterns at SAP

By Gerd Waloszek & Edmund Eberleh, SAP User Experience, SAP AG – November 20, 2003 • Original article (Design Tidbits)

Currently, everyone is talking about user interface patterns, including SAP. Therefore, it is appropriate to take a look at this new concept, discuss its promises, look at its challenges, and ask how the pattern approach is interpreted and used at SAP. This article provides an easy-to-read introduction to software patterns without going into too much detail. More detailed articles on SAP's pattern approach will follow on the SAP Design Guild Website.


The Question – And its Answer...

Have you ever asked questions like "Where can I use icons in my application? Where shall I place the header and detail data? Should I provide collapsible screen areas? How will users search? What about inserting new lines in a table? How to...?" while developing the user interface of your application?

If you have asked such questions (and we know you have!), you know how difficult it is to find good answers. And even if you have found some good solutions for your domain, your colleague, working next door, may have found other, or even better, ones. So, starting with a handful of questions, each leading to a couple of design alternatives, you easily come up with a large number of different user interface variants. Which out of this huge amount of alternatives is the best one; which one is the agreed upon user interface (UI) for your department?

One answer to this challenge is – and the one SAP has chosen – the introduction of user interface patterns in the development process and tools. But before we focus on the SAP approach, let us first take a quick look at the history of the pattern approach and discuss its promises and challenges.


The Origins of User Interface Patterns

Patterns in Architecture

In 1979, Christopher Alexander published his landmark book The Timeless Way of Building. In his book, Alexander argues that excellence in architecture can be achieved by studying a carefully defined set of design rules that are "packaged" in the form of patterns, such as "courtyards which live," "windows place," or "entrance room." According to Alexander, patterns are archetypal solutions to common design problems that aim to satisfy human needs in a certain context.

User Interface Patterns

Inspired by the ideas of Alexander, many UI professionals have increasingly shown interest in pattern concepts for the user interface. Active workgroups discussed patterns on conferences, and the first books on Web site patterns have recently been published. The Web lends itself naturally to using patterns: On the one hand, everyone who uses the Web agrees that you can find a huge and sometimes chaotic diversity of design solutions to the same problem. On the other hand, certain standards have also evolved in the Web's young history. Think, for example, of the wizards in online stores that help users to complete the buying process. The omnipresent shopping basket in online stores may also be regarded as a pattern. To some extent, certain types of PC applications, such as word or image processing programs, and forms-based business software can, in a broader sense, also be considered as user interface patterns. We will, however, see that such a broad interpretation of the pattern approach is insufficient for business software.


Promises and Challenges of the Pattern Approach

Now, let us take a look at the promises and challenges of the pattern approach for user interface design.


For a software company like SAP having its roots in ERP software and heading toward the Web world, patterns are attractive for a number of reasons.


Consistency, introduced by a uniform look and feel of the user interface through the use of a restricted set of predefined components – the UI patterns – requires less learning and relearning from users. As a result, users can focus on their tasks and work more efficiently. A consistent interface also provides the impression of quality, which helps to establish trust between users and the system with which they are working.

Pattern Reuse

On the technical side, we find the following advantages:

  • Reuse of UI patterns follows the maxim "invent and invest once, use in multiple." Once UI designers and developers have a sufficiently large number of patterns at their disposal, the development process is faster.
  • Product quality can be improved because the development builds on thoroughly tested components.
  • The UI can be changed centrally once for all applications that use patterns. This makes design changes easy and allows for new functionality without reprogramming of applications.

Efficient software production

In the short run, application development can be more efficient by using larger UI building blocks because these require less manual work. In the long run, a pattern-based software development process can lead to "assembly line" software production that is largely independent of manual work. In such a production environment, the roles of user interface designers and developers are redefined: Instead of manually assembling controls on screens and consequently being often bound to a local perspective, they select and connect patterns in order to model business processes. Thus, they adopt a broader, process-oriented perspective for their work.


UI patterns also present a number of challenges to software companies. Most importantly, patterns must be well designed in order to cover a broad range of applications. Unsuitable patterns may lead to even less usable applications. Therefore, the selection and skillful combination of patterns play a prominent role in the UI design process. In addition, patterns need to be applied consistently within a coherent business area to be meaningful. Misused patterns lead to inconsistency and – even worse – may also hamper usability.

Visually-oriented designers may fear that pattern usage results in a dull and uniform look to the user interface. To overcome this threat, visual designers are needed who help to build enough flexibility into the patterns, allowing the pattern-based UI to be adapted to a wide range of branding and customizing requirements.

Finally, the dangling question is how many applications can be adapted to a pattern-based UI, and how many handmade screens will remain. A pattern-based UI approach can only be successful for a company if handmade screens become the exception and are restricted to dedicated, demanding applications.


How SAP Defines Patterns

SAP's answer to the challenge of mastering an ever-growing zoo of ERP and Web applications is to introduce interface patterns in the development process and tools. User interface patterns at SAP are generic user interface components with which business applications can be developed efficiently and homogeneously. Let us take a closer look at how SAP defines user interface patterns.

SAP defines user interface patterns analogously to patterns in architecture: A user interface pattern is an archetypal or generic design solution to an interaction problem in the context of a user task.


  • An element-triple – consisting of field label, input field, and explanatory text for the user task of entering/reading data for an object – would be a very simple and small-scale pattern
  • An element aggregate – consisting of a shuffler and a hitlist for the user task of searching and selecting an business object – is a more complex pattern

Role of Task Context

In the SAP sense, the second example is the better one for characterizing SAP's UI patterns because it is a solution to a more general task than just the elementary task of entering data in a field. In general, the task level is the key to understanding at which level SAP defines and assembles patterns. While many controls or simple control aggregates can be regarded as patterns, this is not the level at which SAP defines patterns. Only a sufficiently generalized task will lead to design solutions that can be used in a variety of applications.

Floor Plans and Patterns

To increase the flexibility of patterns, SAP's approach is to separate task issues from layout issues. Let us return to architecture to make this clear: All kitchens serve the same task, preparing meals. The various layouts of kitchens, on the other hand, show a large variety, dictated by the preferences of the kitchen's users and the restrictions imposed by the architecture of the house (see figure 1 as an example). Analogously, while a UI pattern supports a certain task, task details may depend on the respective domain and may require matching screen layouts. SAP calls these layouts "floor plans." In short, the same pattern may be realized by different floor plans.

House floorplan

Figure 1: Floor plan of a family house

Mapping the Task Hierarchy to the User Interface

In our pattern examples above, we described tasks of different complexity and their corresponding UI patterns. Figure 2 provides a more detailed picture of how tasks and their component tasks relate to user interface elements in general and to patterns specifically.

Pattern concept

Figure 2: The SAP pattern concept (click image for larger version)

On the lowest level, we find elementary actions, such as entering text or pressing a button. These atomic tasks typically map to UI controls or small aggregations of controls. On the task level, we find tasks like searching data or editing complex data objects. They correspond to user interface pattern elements, such as compound controls consisting of a filter row, followed by a data row, and a paging row (see figure 2). Tasks themselves are components of activities or composite tasks, such as inspecting data. This is the granularity that corresponds to the level at which SAP's UI patterns are located. A search pattern, for example, may consist of a search area, a set of functions, and a collection area for the hit list. Now, it should become clear why SAP distinguishes UI patterns from floor plans, that is, from layouts. Depending on the task domain, the spatial requirements for a task handled by a pattern may be very different.

With SAP's approach, the highest level combines activities into a workflow. On the user interface side, navigation comes into play and has a prominent role in designing the sequence of screens. Returning to the architecture analogy for one last time, we might say: At this level, we move our attention from one room to the whole floor or even house.


The Present and Future of Pattern Development at SAP

Starting with a few patterns and floor plans, SAP first employed user interface patterns in the People-Centric UI release of mySAP CRM with great success. Currently, this approach is being evaluated and adopted by other development areas, such as Human Capital Management (HCM). The upcoming Web Dynpro development tools will support pattern-based development in the future.

At present, SAP's Usability Engineering Center (UEC) is defining further user interface patterns and further application floor plans for generic tasks such as constructing object hierarchies and guided editing, and for different activities. These user interface patterns and application floor plans will be available to application developers in the Web Dynpro pattern library, which will provide UI solutions at different levels of detail, thus ensuring a consistent and easy-to-learn user interface for all SAP applications.

Based on the experiences from CRM and HCM, the UEC will redefine the current breed of user interface patterns for even better task fit and usability in the near future.




top top