SAP Design System Glossary
SAP Design System Academy / SAP Design System Basics / Glossary
Intro
The following terms are relevant for understanding the SAP design system. Terms are listed alphabetically.
List of Terms
Accessibility
Accessibility refers to the possibility for everyone, including and especially people with disabilities, to access and use technology and information products.
Further context:
Providing accessible solutions is essential for SAP solutions, since many customers have policies in place which mandate that the software they give to employees is accessible. For this reason, SAP has the Accessibility product standard. See the term “Product Standard” for more information. You can also refer to ISO 9241-171.
Application design training material
Application development training material
Brand
Brand drives what a company makes, says and does. It’s the foundation to consistently express ourselves – from the solutions/products we make/develop, to what we say in marketing & communications, across the SAP.com ecosystem and all relative touchpoints (like events etc.), to what we do from our services and operations to our sustainability, diversity, and corporate social responsibility efforts.
Our brand comes to life through every touchpoint and experience a person has with SAP. To help facilitate consistent brand experiences, company-wide guidance is provided which includes everything from logo usage, messaging, tone of voice, font, photography, graphics, and colors.
Common end user processes (formerly “Key end user processes”)
An end user process describes all the steps a user needs to do to get a particular business task done. A common end user process is one which appears in most companies, and which most business people can identify with.
Providing reference designs for common end user processes show how the design system can be used to help a user get their job done easily and intuitively and can provide guidance to product designers if they have similar use cases.
Examples:
Potential such prominent end user processes are:
- Buying some new office equipment, such as a new laptop.
- Selling a product to customers – starting with a quotation, then to a sales order, potentially also up-selling, providing information about availability and likely delivery dates, checking the credit limit.
- Performing performance feedback for an employee.
- Approvals by a manager, e.g., for purchase orders, travel etc.
Common services
All the learning and training material made available to designers of applications, be they technology applications or business applications. Training material can come in many forms and sizes, from online courses, self-learning videos, tutorials, etc.
Reusable backend services which are associated with a specific UI pattern and which are available for use by all application developers. These backend services could be provided centrally for all products, or they could be product-specific services for use by all of a product’s applications.
Examples: “Search”, “Notifications”, “Log-on”.
Further context:
Whether the service is provided centrally on SAP Business Technology Platform or by a specific product, the UI pattern for a common service, defined in the design system content, should be used in all cases.
Company behaviors (how we run)
The set of behaviors that describe how we get things done at SAP on our best day – when everything is running as it should. It describes what makes SAP’s culture unique and special, and gives us direction for making decisions and driving our work every day.
SAP’s five main “How we run” behaviors are:
- Tell it like it is
- Stay Curious
- Embrace differences
- Keep the promise
- Build Bridges, not silos
For design, the value “Embrace differences” means that we are inclusive in everything we do, which leads directly to our valuing accessibility in our solutions.
Further context:
See them defined here: in sapedia, and in the SAP Strategy one-pager.
Component
A reusable building block, also known as a UI element, for creating a user interface.
Design defines what the component looks like and its interaction behavior, independent of the technology used to implement it. Designers can reuse components when designing patterns, floorplans and when designing applications.
Technology libraries and frameworks can provide developers with reusable implementations of components, examples being UI5 Web Components, or the component libraries provided with the SAP BTP SDK for iOS and for Android. Note that in technology, the term “component” is used more broadly, covering not only designed components but also patterns etc.
Examples: Button, Switch and Text input field. Components can be used to build patterns. For example, the card component is used to build list cards or object cards, which are patterns.
Component library
A library of components for reuse.
Example for developers: UI5 web components, native mobile components provided by the SAP BTP SDK for iOS and the SAP BTP SDK for Android.
Further context: see the term “Library”.
Consistency
Consistency describes the quality of the relationship between your user’s expectations – his or her mental model – and your product.
Presented information is consistent if items of information with similar intent are presented similarly and items of information with different intent are presented in different style and form within and across the interactive systems and the user’s environment. [From ISO 9241-112]
Consistency is achieved when elements of a UI with similar intent have a consistent look and feel and behave in a similar way. This means that users who are familiar with one application will find it easy to learn and use a new application if the UIs are consistent.
“Consistency is one of the most powerful usability principles: when things behave the same, users don’t have to worry about what will happen.” – Jacob Nielsen
A consistent user experience reduces learning efforts and eliminates confusion.
Examples: applications with the same color themes will appear consistent. Using the same typography (fonts and font usage guidelines), icons and terminology are important for providing consistency. Having a common header bar design at the top of the screen also provides a consistent experience. Also using similar components, patterns and floorplans helps consistency – for example using the same design pattern for a date picker. Consistency also applies to interaction design, for example how a button reacts to a “mouse-over”, as well as the animation provided when clicking on the button.
Further context:
This series of blog posts explains consistency in more details, and starts with this one:
The Best User Experience Is Consistent – Part 1: About Consistency
Design guidelines
Design language (synonym: “style”)
Defines the style to be used, based on brand guidance: colors, icon style, logos, illustration style, typography (font, e.g., “72”), grid / metrics, sound, motion, shadows, tone of voice, shapes (e.g., “roundness of corners”).
Further context:
SAP uses the same design language across all points on the customer journey, including marketing, viewing products on SAP.com and within the product experiences.
Design practices
Design principles
Core guiding principles that apply to all UI design at SAP. They apply to the design system itself but also to all application designs.
Example: The SAP Fiori design principle “role-based” means that UIs should be designed to meet users’ needs and intentions, making their work easier (rather than providing a one-size fits all application for many different users with different roles).
Example: The SAP Fiori design principle “simple” means UIs and UI elements should be effortless and intuitive: eliminating overload, friction and surprises.
Example: The SAP Fiori design principle “coherent” means applications should be seamless and cohesive: delivering one fluid experience within and across SAP solutions.
Design rationale [of the design system]
Design specification
Design system asset
Design system asset library
A library of design system assets provided by designers for reuse by product developers.
Examples of assets in an asset library are icons, fonts, illustrations, sounds.
Design system element
Design token
Design tokens are invisible pieces of a design system such as colors, metrics, typography scale, font faces (light, black, etc.). They are used to specify the values for these individual pieces to be used in a theme for specific aspects of UI designs, ensuring consistency across multiple applications. Design tokens allow different themes to be defined by using different values for the individual tokens. Design tokens should be constant over time.
Example: specifying the exact style values to be used for “sapBrandColor”. The design style definition of “sapBrandColor” is known as the design token which would have a 1:1 match with the corresponding theming parameter (CSS variable) for the technology.
Design tokens can refer to other design tokens when specifying aspects.
Example: A design token for “sapButton_Emphasized_Background” could get its value from the design token, “sapBrandColor”. The corresponding mapping of these styles matches also within the implementation.
Variations of a given theme can be made by changing only a small subset of design tokens.
Examples: a theme could be a dark theme and high-contrast themes of a light theme, such as Morning Horizon.
Further context:
Design tokens are elements of the design system in the design domain. They can be mapped directly 1:1 to theme variables in the theming structure provided by a technical framework which supports theming. In other words, a design token for “sapBrandColor” should map to an equivalent theme variable.
Development guidelines
Floorplan
A composition of smaller UI parts, such as patterns and components. A Floorplan describes a UI layout consisting of patterns and components which covers a frequently occurring use case. A Floorplan typically describes the content of a complete page or even spans several pages. Floorplans are meant to be reused by application designers.
Examples: a floorplan for displaying or editing a business entity such as a customer, product, or employee, or for working with a list of entities, or for providing a wizard.
Foundations [of the design system]
Defines the underlying thinking behind the design system at a meta-level. The design language can be seen as covering the foundations of the visual design. However, the foundations overall also cover interaction design, tone of voice and all other aspects of the design system.
An understanding of the foundations is a prerequisite for designing new components, patterns, or floorplans for the design system or for enhancing existing ones with new capabilities: it ensures that these new or enhanced entities can be seen as belonging to the design system. In other words, the foundations secure the quality of the design system, by ensuring that nothing is designed which doesn’t fit with the rest of the design system.
Interaction design foundations
Interaction design is the description of the interactions needed to be performed and completed by the user to achieve his tasks and the corresponding goal. The Interaction Design Foundations define the expected behavior for all design system elements with regards to all the types of interaction behavior.
Examples: Defining how scrolling should appear, common parts in keyboard behavior, using the right gestures, defining how drag & drop should be visualized.
Library
Provides a set of reusable parts (such as icons, fonts, components) for designers, available in design tools such as Figma.
Libraries also exist for developers, available in code frameworks such as UI5, React, Angular etc.
Naming conventions
Naming conventions lay down the rules for how to name things which are shown to users. For products these include terminology.
Example: defining which texts to use on buttons, whether to use “Edit” or “Change”.
Further context: Naming conventions also play a big role when applying the design system to the creation of marketing assets.
Pattern
A composition of components along with possible user interactions to cover specific, smaller common use cases. Patterns are meant to be reused by application designers.
Examples: exporting data to Excel or PDF, or a pattern for confirming or cancelling an action, or filtering a list (including actions for selecting filter parameters and saving views). Also, compositions of components such as a card with list items are patterns.
Product standard
SAP has several internal Product Standards, which are binding for all products. Product standards define aspects of SAP products which all products need to adhere to. Non-compliance could potentially have revenue and/or legal implications.
Examples:
Specifically for UX we have these product standards:
- Accessibility
- User Experience Consistency
The accessibility standard defines what products need to do to provide an accessible user interface compliant with accessibility regulations in our global markets.
The UX consistency standard defines which aspects of product designs need to be provided by all applications, in order to provide a certain amount of UX consistency for users who use more than one product.
Although not directly classified as a UX product standard, the standard “Performance” is also important for UX, since a good UI has fast response times. The standard “Functional Correctness” is also related to UX, since a buggy application provides a poor user experience. Other related product standards which are partly relevant for UX are “Globalization”, “Integration” and “User Assistance”.
Further context – Accessibility standard
SAP Product Standard Accessibility is based on external and globally acknowledged accessibility guidelines, that are frequently requested by our customers to be realized in our products.
The Standard is always applicable for all kinds of products, if there is at least a single UI.
The 31 requirements of the SAP Product Standard Accessibility are clustered into six main topics:
- Information & Text
- Visual Perception
- Attributes and Identification of UI Elements
- Orientation and Navigation Within the Application
- User Interaction Within the Application
- User Interaction With Time-Dependent Content
When following the SAP Product Standard Accessibility, your product will be globally competitive and will comply with SAP’s Diversity & Inclusion strategy.
Further context – UX Consistency standard
SAP Product Standard UX Consistency defines consistency
requirements for:
- Colors
- Theming Concept
- Typography
- Iconography
- Action Placement
- Terminology
- Shell bar
- Settings
Reference application
An example application which demonstrates key concepts implemented according to the design guidelines, showing how to use a set of components, patterns and/or floorplans when designing an application.
No single reference application can cover all aspects of the design guidelines, each one would typically focus on a certain area. Multiple reference applications would be needed to give a reasonable coverage of the design guidelines.
Further context:
Component code samples should also reflect the design guidelines and intent.
Release [of the design system]
System design guidelines
Technology reuse libraries
Libraries of common technical components and assets that can be used universally across different products, provided by technology component and asset libraries.
Example: UI5 web components, native mobile components provided by the SAP BTP SDK for iOS and the SAP BTP SDK for Android; fonts, icons, illustrations and sounds (audio).
Further context:
Note that this reuse layer is not the same as a UI framework, but it is intended to be used by UI frameworks.
Theme
Specifies the color palette, icon library, illustration library, font usage (e.g., when to use bold), grid / metrics, interaction sounds, motion, shadows, focus visualization, tone of voice, and shapes e.g., “roundness of corners”) for UI components. A theme can have concrete variants, to cover light and dark environments, or to provide better accessibility. These variants are also referred to as themes – which means that the term “theme” can refer to the collection of variants as well as to one of the variants itself.
Example: The Horizon visual theme is defined by the elements of SAP’s design language and reflects the current version of the design language. There are four variants of the Horizon theme “Morning Horizon”, “Evening Horizon” plus high-contrast black and white theme variants. Each of these variants are also called themes, and users can be provided with a settings menu where they can choose which theme they want to use, by selecting one of them. In other words: we have the overarching Horizon theme, and we have the four more concrete themes, “Morning Horizon” “Evening Horizon” plus high-contrast black and white themes.
Further context:
A single theme variant can be implemented by applications in many ways – via a UI framework which supports a theming structure, but it could also be hard-coded into a UI framework or even into individual applications. Note that applications with the theme variant hard coded typically do not support multiple theme variants, such as a standard theme and a high-contrast version, so we strive to avoid hard coded solutions going forward.
A theme can be specified in the design domain by specifying values for design tokens. A theme can be defined in technology by defining the values for theme variables in the theming structure.
Theme variable
Theme variant
A more concrete specification of a theme. A theme variant is normally also referred to as a theme.
Note that the term theme variant is not used in external communication, nor on product UIs where users can see a list of themes available in the system.
Example: There are four variants of the Horizon theme “Morning Horizon”, “Evening Horizon” plus high-contrast black and white themes. Each of these variants are also called themes, and users can be provided with a settings menu where they can choose which theme they want to use, by selecting one of them.
Further context:
A theme variant can be specified in the design domain by specifying the values for all design tokens.
Theming
Theming structure
The collection of design tokens and their relationships stored in a central repository. Design tokens serve as a base for creating theme variables. Ideally, each theme variable corresponds to a design token. The theming structure allows applications using this runtime technology to display various themes by using different values for the individual variables. If possible, theme variables should be kept constant over time.
Examples of themes could be a light and a dark version and high-contrast themes delivered by SAP but could also be custom-defined themes.
Further context:
UI technology frameworks which provide a theming structure enable switching between different themes. This way, the same application can look very different, depending on the user’s design preference or accessibility requirements. For example, such a framework would allow customers to switch between the four Horizon themes, e.g., Morning Horizon and Evening Horizon, or the two high-contrast Horizon themes.
For applications built using a UI technology framework which provides a theming structure, it is possible to create a new theme for all such applications without modifying the applications. If the UI technology framework gives customers access to the theming parameters, then they can define custom themes without modifying the applications, or choose to use other SAP delivered themes such as the Quartz themes and the Belize themes.
Theming support [by a UI framework]
Tone of voice
Tone of voice is the communication style that influences how users feel about what we are conveying. It is applied to UI content such as labels, menus, messages, illustrations, in-app help, and digital assistant conversations.
Voice reflects our brand personality and its underlying values. The voice is always consistent and applies to all UX content.
Tone conveys the mood or feeling we present to the user. The tone can vary, depending on the situation or audience.
Examples for voice: “trusted”, “relatable”.
Examples for tone: “professional”, “business casual.” New end users like encouragement and the occasional “You did it! Good job.” Expert users, not so much. They prefer you’re more to the point. Similarly, the tone for messages around data protection and privacy, or legal aspects in general, are likely to be more serious than for other contexts.
Further context: SAP Brand tone of voice
UI element
Entity of the user interface that is presented to the user by the software. UI element is often a synonym for component.
Example: The UI elements can be texts, graphics, component, patterns, floorplans, but also sounds.
Further context: UI elements are the subset of the design system elements which are presented to the user. Hence design tokens are not UI elements.
UI framework
Runtime technology providing the code to allow developers to build application UIs out of reusable components and libraries from the technology reuse layer. Frameworks take care of allowing individual UI elements to interact with each other.
Example: SAPUI5 is a JavaScript / HTML5 based UI framework, which enables developers to reuse UI5 web components as well as other components, patterns and blueprints and libraries.