Overview

The BTP product landscape primarily contains complex products targeted at developers, architects, data scientists, and other technically proficient users. High information density screens are standard, and utilizing space efficiently is an essential priority for many BTP Tools. We have designed several BTP components and component extensions to satisfy those needs.

BTP UI Components

Legacy Guidelines

The BTP Experience Toolkit aims to provide design guidelines harmonized with the latest version of the SAP Design System. This harmonization is a process, and older guidelines (marked with Pre-Horizon) will coexist with the already updated ones. Additionally, the previous version of the guidelines remains valid for products not adopting the latest version of the SAP Design System.

AppDev and Integration Design Guidelines

Data and Analytics Design Guidelines

Standards

UI components' usage, extension, and development must be carefully considered. They are rooted in our most basic standards and meet the requirement of the SAP Design System. If you are using a component from any of the SAP UI framework libraries, prototypes are built into them. Still, if you choose to design a custom one, you must meet the requirements below to provide the highest quality user experience.

guideline

Things to Consider

  • Context
  • Users
  • Design Language
  • Responsiveness
  • Accessibility
  • UI Element States
  • Theming

See also:

Fiori for Web Design Guidelines

Testing and Research

Designing with the standards in this guide is not an accurate pass or fail because they are not absolute values. But exactly how you use them will determine much of your success. As such, always test custom components with as many internal and external users as possible, and make evidence-based and data-driven changes.

Documenting New Components

Not every custom component must be documented in the BTP Experience Toolkit. If you have one that has been well-researched, adequately tested, and with high reuse value, contact us so it can be documented and made available to the rest of the organization.

Context

Context plays a significant role in creating components. All components must fit in an existing ecosystem of established components, pages, products, and suites. With that in mind, consider how your colleagues solved the same or similar problems in their product areas. Seek several examples, from more than one designer, on how it has been done before. Understanding the context is understanding your user's mental model.

It is tempting to think your use case is unique, but think beyond the content it represents and instead look for the problem it’s trying to solve. Anyone can see how the two components are different, but it takes maturity to recognize their similarities. The system designers in BTP Experience are here to help you identify similarities and connect you with others with similar issues.

As a rule of thumb, it is preferable to unify similar experiences than design custom, tool-specific components. Standardization reduces the time to design, maintain and implement features. It also has the added benefit of making the components future friendly.

Users

When designing components, it is vital to remember who your users are. What are their persona type, needs, habits, challenges, and the tools they are accustomed to using? The better you know your user, the easier to make informed design decisions.

BTP User Type Matrix

Often, users do not know what they need, and when asked directly, they will request more of what they already know. Focus on observing and learning from your users and consider a solution that works in our context (see above). Meet your users' needs through intelligent and consistent design decisions based on observation, not by giving them what they asked for.

See also:

NN Group - Don't Listen to the Customers

Just because you might be dealing with a specific user type, it doesn’t mean they need entirely new components or new ways of using existing features - especially for generic ones like clicking on buttons, opening menus, making selections from a dropdown, or navigating to a new content area. Some things need to work as expected without any gimmicks.

Consider other designers and developers as users as well. Please think of how they could reuse your custom component and implement it in another context to solve a similar problem in the future. How do you avoid making it so specific to your use case so that it can be reused again?

Design Language

Creating a component must still speak the same visual language as SAP products. Strive for a recognizable look and feel using elements from the SAP Fiori design language, such as color palettes, typography, iconography, size, spacing, shadow principles, etc.

Resources Articles on Visual Design

See also:

Fiori for Web Design Guidelines - Look, Feel, and Wording

Responsiveness

BTP product screens are typically designed in 1440px width. While this is a perfect middle-of-the-road size, not all our users use this size. When creating custom components, smaller sizes, and touch interactions need to be considered. Responsiveness is built into the UI framework components but needs to be implemented manually into any custom components, patterns, and layouts. You are responsible for ensuring your custom component is responsive to different screen sizes.

Tool Header Responsiveness

Avoid hardcoding exact size values, as this is your first indication of working against responsiveness. Instead, consider what your component will look like at different screen breakpoints and how overflow behaviors come into play at different sizes. The screen breakpoints defined for BTP are:

<div> <div>Size</div> <div>Range</div> <div>Columns</div> <div>Column Gutter</div> <div>Row Gutter</div> <div>Padding</div> </div> <div> <div>Size S</div> <div>from 0 to 599px</div> <div>4</div> <div>0.5rem</div> <div>0.5rem</div> <div>padding: 0 0.5rem;</div> </div> <div> <div>Size M</div> <div>from 600px to 1023px</div> <div>8</div> <div>1rem</div> <div>1rem</div> <div>padding: 0 1rem;</div> </div> <div> <div>Size L</div> <div>from 1024 to 1439px</div> <div>12</div> <div>1rem</div> <div>1rem</div> <div>padding: 0 1rem;</div> </div> <div> <div>Size XL</div> <div>from 1440px to 1679px</div> <div>16</div> <div>1rem</div> <div>1rem</div> <div>padding: 0 1rem;</div> </div> <div> <div>Size XXL</div> <div>from 1680px to infinity</div> <div>20</div> <div>1rem</div> <div>1rem</div> <div>padding: 0 1rem;</div> </div>

See also:

Responsiveness Design Standard

Accessibility

Accessibility on the component level is crucial. It means that everyone can interact with all component features on any device. It is the foundation of an inclusive approach to designing and building products.

Accessible Typography

guideline

Things to Consider

  • Multi-device support and responsiveness.
  • Contrast ratios between text and elements and interactive elements and their background.
  • Text resizing when zooming.
  • Initial focus position, tab order, and group skipping.
  • Keyboard, mouse, and touch interactions.
  • Support for screen reading technologies.

See also:

Accessibility Design Standard

Globalization Design Standard

UI Element States

Using the correct state or combination of states for a UI element helps users recognize possible options and see where to take action. Depending on the component, different types of states are supported:

See also:

Fiori for Web Design Guidelines - UI Element States

Theming

The ability to theme is a UX Consistency Product Standard. The standard requires products to implement colors via theming variables, thus eliminating the use of hard-coding color values. When designing components' visual design, assign the colors to semantic control parameters via the CSS variables. When choosing a parameter, make sure the name of the parameter fits the purpose of its usage.

guideline

Things to considerComponents vary between standard and high-contrast themes in many aspects besides color. Such as:

  • Roundness
  • Borders and border thickness
  • Shadows
  • Approach to value states

See also:

Visual Core Wiki - Semantic Color Parameters