User Interface Guidelines – An Introduction

By Bernard Rummel, SAP User Experience, SAP AG – October 8, 2009

SAP's UI design strategy reflects a paradigm shift in its approach to user interface design. It is characterized by the transition from a rather transaction-centered approach towards user-centered methodologies and concepts.

This affects both the design methodology, described in SAP User-Centered Design, and the concepts and entities which are finally exposed to the user, as described in user interface design guidelines. The SAP User Experience team is leveraging the fast-paced evolution of UI technologies in order to drive those conceptual changes, while at the same time fostering an overall harmonized user experience.

 

Lessons Learned from User-Centered Design

Five central observations drive the UI concept underlying the present guidelines:

  • User and business needs come in patterns, but still they vary.
    The challenge is to cover the invariant parts with stable UI design patterns, and to provide easy customizing, configuration, and personalization capabilities in order to cover the variability.
  • People work in multiple, parallel activity threads.
    Consequently, it is essential to support parallel work activities in the user interface.
  • Work activity threads need to be organized, in particular in case of parallel threads.
    To support this, we provide central role-based UI "hubs" where work threads originate: we collect all content to organize, trigger, and inform the user's work on role-specific work centers. All work centers of a user are collected in one dedicated, browseable window, typically the SAP Enterprise Portal or SAP NetWeaver Business Client main window. The home page of this Portal is to summarize information across the user's entire work environment, and also to provide comprehensive content directories as well as role-independent content.
  • Activities can be categorized and supported by standard UI "floorplans."
    The obvious variability in user activities can be covered by variable configurations, and by connecting applications through carefully selected, context-based navigation links.
  • People think in terms of "things" and "things to do."
    Together with work centers, worklists, floorplans for object instances (OIF), and activities (QAF, GAF) form the backbone of the SAP Business Suite user experience. 

 

Supporting the User's Work Organization

Every work activity is motivated by explicit work triggers, like a task, or implicit work triggers, like business information. The user needs to collect this information, decide on what to do first, and find a quick way to start the respective activity. Common work triggers are:

  • A task given by a supervisor
  • Items to be processed in the user's area of responsibility (worklist)
  • A business report or news item indicating an exceptional situation that needs being dealt with
  • A customer (external or internal) calling with a question, or a service request

Control & Work Centers

Many work triggers can be addressed by assembling content building blocks on dedicated pages on the basis of user roles. As an infrastructure for doing so, for instance, the SAP Enterprise Portal offers a variety of content management frameworks. There are of course many work triggers which are not modeled in the system; for those, the user needs a well-organized access to the applications s/he needs. We collect all content to organize, trigger, and inform the user's work on work centers. Work centers are based on specific nodes (worksets) in the Portal Content Directory (PCD). The (Portal) pages built on this infrastructure are called work center views. All work centers of a user can be accessed and browsed in one dedicated window, typically the SAP Enterprise Portal or SAP Netweaver Business Client main window. The home area of this portal, the Control Center, summarizes information across all work centers, and provides cross-role content directories as well as role-independent content. Note that work centers support the user in organizing her work – not in doing it. Consequently, apart from single-click actions, work centers are strictly read-only. Concretely spoken, there is no Save button on the work center. Work centers don't support complex information gathering and analysis tasks either, since such tasks also would suffer from interruptions and task switches, and would also need to be integrated into the user's work organization. Consequently, work centers can launch respective applications, and provide excerpts, but they never contain the full application itself.

On Work Center Views, typical standard iViews are monitors, like the BI Information Consumer Pattern (ICP) and the Generic Key Figure Monitor (GKFM), and worklists (see below) like the Universal Worklist (UWL) and POWER List (POWL).

Custom iViews, for example, news feeders etc. are possible, as long as they address the purposes to organize, trigger, or inform user work and do not involve extensive work activities in themselves. For work triggers not modeled in the system, the Work Center View provides links to respective applications. For each role, all such services are collected and briefly explained on a dedicated directory page called the Service Map. In addition, reports pertaining to the respective area of work are provided in a commented directory on a Reports or Analytics View. 

Bringing Work to the User: Worklists

Explicit work triggers, such as tasks or objects the user is to process, are actively provided to users on dedicated worklists. Such worklists can be based on SAP's Business Workflow infrastructure (for example, the Universal Worklist), personal preconfigured database queries (for example, the Power Work List - POWL), or suitable search infrastructure (as in the SAP CRM Web UI Framework). From each work item, the user can navigate by link directly to the respectively parametrized application floorplan. The look and feel of these worklists is much like an inbox – the user sees a list of items to do and can engage in the work process by a single click.

As an example, the POWL allows administrators to easily distribute work objects to individual users. Users can – if authorized – modify the corresponding queries and create personal variants. The number of items in a list is shown to the user, so it is possible to immediately assess the workload contained in an individual worklist.

 

Performing Work: Floorplans

As a pragmatic approach to categorize work activities for system design, the following categories have proven quite stable and sensible:

  • Quick Activity
    Some simple activities can be performed in one step on one screen.
    Supported by: Quick Activity Floorplan (QAF)
  • Guided Activity
    If the user has insufficient knowledge or practice in either the work process or the tool we provide to perform it, the system is to provide guidance. The activity is sequentialized so the user can perform it step by step.
    Supported by: Guided Activity Floorplan (GAF)
  • Editing a Business Object Instance
    Most office data are collected and managed in the form of business records or "objects." The basic work activity related to these objects is to edit the relevant properties of the object, and to put it back on the database.
    Supported by: Object Instance Floorplan (OIF)

Of course there are numerous other task categories, like comparing business objects, manipulating object sets, hunting for exceptions, planning and simulation, browsing through object hierarchies etc. The ones outlined here are currently supported by standardized UI design solutions. There is also an application development framework available, the Floorplan Manager for Web Dynpro ABAP.

 

Designing for Variability

User needs and customer organizations vary, and they do so over time as well. Consequently, any UI framework and design approach must cover the relevant variability, but without introducing unnecessary inconsistencies.

The key to this dilemma is to provide suitable designtime environments.

On the user role and work center level, the SAP Enterprise Portal and SAP NetWeaver Business Client provide infrastructures to assemble and distribute work centers to users, based on user roles. The structure of UI building blocks – for example, the interaction design of a POWL – remains stable in this distribution process, but the content can vary depending upon the user's business needs.

On the floorplan level, the Floorplan Manager for Web Dynpro ABAP (FPM) provides a framework for building standardized UIs, based on the classification described above, conforming to SAP layout and interaction guidelines. At the same time, the FPM supports capabilities to change the application configuration without changing any code (modification-free). By this, a customer can easily create fine-tuned variants for a specific user role's needs, and distribute those variants via the role model. The same holds true for the CRM Web UI Framework which is an equivalent offering for building applications in a CRM driven environment.

 

Fostering Consistency: UI Governance and Harmonization

A rapid evolution of UI technologies has introduced a lot of variance into the design of SAP application UIs. The SAP User Experience Team has leveraged those variations in order to drive the conceptual evolution. At the same time, there is a constantly ongoing harmonization process in order to preserve or reintroduce consistency in the user experience.
UI harmonization is being addressed on five levels:

  1. Brand unification: Align visual design of product items and branding of marketing material
  2. Common UI look: Harmonize visual design of clients and UI controls
  3. Common navigation: Align navigation to and between applications
  4. Common interaction: Align interaction behavior within the applications
  5. Consistency across systems: Ensure a harmonized interoperability of scenarios across systems

The "Look" levels 1 and 2 are covered by visual design specifications created by a central visual design team. All visual designs controlled via stylesheet can be adapted by the customer.
The "Feel" levels 3 to 5 are addressed via the UI Governance Framework, which covers both framework development and UI design guidelines. All new UI controls, icons, and guideline change requests go through dedicated governance processes.

 

top top