Developers are faced by a great many questions when designing the user interface, or UI, for a corporate software application. Should they use icons? Where should the header data and the detail data be positioned? How do users search for objects or data? How should new rows be inserted into a table? Which working areas should make up a view?
Finding the right answers to all these questions is not easy. This is why SAP uses predefined “floor plans” that are populated by reusable generic “user interface patterns” when developing user interfaces. As part of a user-centric design process (“user interface first”), developers design business applications and configure their user interface using predefined components. They are assisted in this task by appropriate development tools.
The pattern approach at SAP
Reusable components, or patterns, are not new concepts in software development and user interface design. According to the definition of design experts Douglas van Duyne, James Landay, and Jason Hong, they provide insights into design problems by defining the specifics of a particular issue and its solution in a compact form. A well-known example would be the shopping cart used by online shops, where users can collect all the items they want to buy before placing the order.
The pattern approach at SAP is characterized by two special features. Firstly, it separates the description of a task that the user executes from its representation on the user interface. This separation has the advantage that the floor plans and components can be structured both according to the prevailing design paradigm and also in line with the specific features of the terminal, such as a large monitor on a PC or a small monitor on a PDA. Secondly, the approach only works if generic user interface solutions are found for generally applicable, or “generic”, tasks – after all, the intention is to be able to use one component for a large number of applications. Both tasks and the elements of the user interface can be mapped in a nested “decomposition hierarchy”, that is, simple elements can be combined to produce more complex ones.
The “search for a work object” is one example of a generic task. It is irrelevant whether the object is an order, a delivery, an invoice, or a material. The general assumption is that if generic tasks exhibit similar properties for a specific number of business processes, then a standard solution can be found on the user interface. For instance, a button represents a “classical” solution for the generic “trigger function” problem.
The SAP approach is about moving away from the level of these elementary actions and solutions, such as entering text or clicking a button, and identifying more complex tasks. To achieve this, elementary components, or “user interface controls”, such as the button, are assembled into more complex components, the “pattern elements”. A pattern element may be a toolbar that combines several controls for triggering functions. Pattern elements themselves can be combined into even more complex components, the user interface patterns. A user interface pattern fulfils one or more generic tasks, such as searching for and selecting a business object. A pattern such as this may consist of a search area, various function buttons in a tool bar, and a collection area for the hit list.
Standardized floor plans for applications
During application development, user interface patterns are combined into application floor plans, and are arranged on the screen. The application floor plans can be standardized for identical application types (“business activities”), such as editing a customer order. One part of the “people-centric” mySAP Customer Relationship Management (mySAP CRM) solution, which marks the beginning of the deployment of user interface patterns at SAP, consists of just two floor plans and uses only two different user interface patterns. This provides for a highly consistent solution. However, it is only possible to do with a small number of floor plans in this application area because the applications have a similar structure. Naturally, more floor plans and user interface patterns may be used to make the application more suited to the needs of the user.
SAP bases its development of user interfaces on Karen Holtzblatt’s “Contextual Design” method, which takes the users’ working practices as its starting point. Developers and UI designers use this method to create the model of an interaction structure (“user environment” model), that is, the structure of a business process from the user’s point of view. The interaction structure consists of discrete areas, known as the focus areas, each of which describes a user activity, such as entering invoice line items. A focus area is defined by its purpose for the user, by other areas to which the user can navigate, and by functions available to the user. According to Holtzblatt, the user interface should represent a focus area as a coherent whole on the screen that allows users to concentrate on it and complete their tasks there.
Focus areas are normally derived for one specific business process and are only valid for this. However, the SAP approach requires similar focus areas to be defined from different business processes. Only then can reusable UI components be built that can then be configured for each specific application scenario. One result of this is a consistent user interface structure of different applications that have a similar composition.
However, the approach only works if there are a small number of “generic” tasks, which can describe very many different business activities.