The Database, Data Management and Analytics design system is a living and breathing product that will continue to evolve as our organization and product offerings grow. But product teams may still find the need to create custom components on occasion. This should be done responsibly and with special care for our foundational consistency standards.

7 Standards to follow

Please follow the 7 standards below when designing custom components. They are rooted in our most basic standards and meet the requirement of Fiori apps. If you are using a component from the UI5 library, these things are built into them, but if you choose to design a custom one, then it is your responsibility to meet them in order to provide the highest quality user experience.

Testing and research

Designing with the 7 standards in this guide is not an exact 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 changes that are evidence-based and data-driven. If you require support for testing and research, please contact your local design services team.

Documenting new components

Not every custom component will need to be documented in the Database, Data Management and Analytics design system. If you have one that has been well-researched, properly tested, and with high reuse value, please contact the design system project team so it can be documented and made available to the rest of the organization.

1. Context

Your custom component will need to fit in an existing ecosystem of established components, pages, product, and family of products. Your custom component can’t exist independent from this context, so consider how your colleagues solved the same problem or similar ones in their product areas. Seek several examples, from more than one designer, on how it’s been done before. Understanding the context is understanding your user's mental model.

You might be tempted to think your use case is different, but think beyond the content it represents, and instead look for the problem it’s trying to solve. Anyone can see how two components are different, but it takes maturity to recognize how they are similar.

Only then, decide if you should re-use an existing component or design a new one. If you make updates to the existing one, discuss with your colleagues how to unify these experiences.

2. Users

Who are you designing for? What research is available about their persona type, needs, habits, challenges, and the tools they are accustomed to using? The better you know your user, the easier it becomes to make informed design decisions. But a few points to keep in mind:

• Often times, users don’t 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 user’s needs through smart and consistent design decisions based on observation, not by giving them what they asked for.
• Just because you might be dealing with a specific user type, it doesn’t mean they need an entirely new components or new ways of using existing components — especially for generic ones like clicking on buttons, opening menus, making selections from a dropdown, or navigating to a new content area. Some things just need to work as expected without any gimmicks.
• Consider other designers and developers as users as well. Think of how they could re-use your custom component and implement it 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 re-used again?

3. Design Language

When creating a custom component, it still needs to speak with the same visual language of SAP products. Strive for a recognizable look and feel by using elements from the SAP Fiori design language, such as colour palettes, typography, iconography, size, spacing, shadow principles, etc.

4. Accessibility

Accessibility means everyone, especially those with disabilities, can access and use information and communication technology. It is an inclusive approach to designing and building products.

SAP Fiori and SAPUI5 include a large set of controls with features that support accessible implementation, including keyboard enablement, resizing behavior, or support for theme changes. If you are designing a custom component, it is your responsibility to ensure these same features are implemented manually.

Design and build for accessibility by considering:

• multi-device support and responsiveness
• high contrast ratios
• text resizing on zoom
• initial focus state position, tab order, and group skipping
• keyboard, mouse, and touch interactions
• support for screen readers with alternative texts

72’s design is optimized for legibility, readability and ultimately, accessibility.

5. Responsiveness

We design for screen sizes of 1440px wide but most of our users have different screen sizes, often smaller than this. Responsiveness is built into Fiori UI5 controls but needs to be implementing manually into any custom component outside of the UI5 library. It is your responsibility to ensure your custom component is responsive to different screen sizes.

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 come into play at different sizes. The screen breakpoints defined by Fiori are good starting point:

• S: Up to 599 pixels
• M: Between 600 pixels and 1023 pixels
• L: Between 1024 pixels and 1439 pixels
• XL: 1440 pixels or more

Designing icon tab bar for responsive and overflow behaviours

6. Interaction States

In addition to interaction states like regular, hover, pressed, and disabled states, consider all additional states your custom component and its data needs to go through for successful interactions, such as:

• Empty state – what the control looks like with no data or selection
• Focus states – the starting focus position and subsequent focus on tab order
• Busy state – and the placement of a busy indicator
• Value states and messaging – semantic color parameters, icons, and messages
• Read-only state – clearly distinguishable from default and disabled states
• Completed state – how the control gives visual indication of completion
• Edit state – showing the control or its data in an edit state
• Reset state – showing how to remove, reverse, cancel, or delete the user’s input data

7. Theming

Reduce or eliminate the use of HEX codes on their own. Find the appropriate parameter name from the Fiori library to ensure you are using just the right kind of blue. Parameter names should not be used at random or interchangeably just because they match your desired hex code.

Ensure the right parameter name for the sake of theming and color mode changes (ie., quartz light vs quartz dark).

The Database, Data Management and Analytics design system is a living and breathing product that will continue to evolve as our organization and product offerings grow. But product teams may still find the need to create custom components on occasion. This should be done responsibly and with special care for our foundational consistency standards.