SAP Fiori Design Guidelines

The guidelines describe how SAP Fiori apps should look, behave and communicate. The main areas are:

• Principles — the five ideas behind every design decision.
• Visual foundations — color, typography, iconography, spacing, theming and wording.
• UI elements — guidance per control: when to use it, when not to, and how it should behave.
• Floorplans — complete page structures for recurring tasks, such as the list report, the object page and the overview page.
• Patterns — cross-cutting behavior such as messaging, draft handling and navigation.
• UI kits — design files that let designers mock up screens with the same components developers use.

There are separate editions for web, iOS and Android, because native mobile apps follow their platform conventions while keeping the SAP Fiori design language. Since 2025, the guidelines are part of the broader SAP Design System portal on sap.com. The SAP Fiori Design Guidelines are therefore a full design system, not a style sheet.

SAP names five principles for the SAP Fiori user experience:

The fifth principle asks for an experience that makes an emotional connection with users and makes their work easier. The principles are deliberately abstract. They become concrete in floorplans and UI element guidance, which is where design reviews usually point. The five SAP Fiori design principles are the yardstick; the rest of the guidelines show how to meet it.

The guidelines describe the intended result; the technologies produce it.

• SAPUI5 provides controls that already follow the guidelines visually, but a developer can still combine them into a screen that breaks the intended behavior.
• SAP Fiori elements implements selected floorplans as metadata-driven templates. SAP's developer guidance lists automatic SAP Fiori compliance as one of its benefits, because the layout and behavior come from SAP's framework.
• Freestyle SAPUI5 apps reach compliance only through deliberate design work, since every layout decision is custom.
• UI5 Web Components bring the same visual language to other web frameworks.

This is why many teams pick the floorplan first and the technology second: if a floorplan fits, SAP Fiori elements delivers it with less effort. The SAP Fiori Design Guidelines answer "what should this app be?", while SAPUI5 and SAP Fiori elements answer "how is it built?".

SAP Fiori's visual design has evolved several times since the original task-focused apps, with theme families such as Belize and Quartz followed by the current SAP Horizon theme family. Each step kept the principles but changed the visual language, the launchpad experience and the available patterns. In SAPUI5, SAP Horizon appears as themes such as Morning Horizon and Evening Horizon.

Two practical consequences follow:

1. Guidance is version-dependent. The web guidelines are versioned along SAPUI5 releases, and SAP updates only the latest guideline version, so a team on an older on-premise front-end server should check which guidance matches its release.
2. The location moved. The guidelines now live in the SAP Design System portal, and older bookmarks redirect there.

Reading the SAP Fiori Design Guidelines for the wrong version can turn a design review into a dispute about features the system does not have.

The guidelines are most useful at the points where design decisions get locked in:

• Requirements: describing a custom app as "a list report with an object page" gives business and IT a shared vocabulary before anyone writes code.
• Technology choice: if a standard floorplan covers the requirement, SAP Fiori elements is usually the cheaper path; if not, freestyle development is justified.
• Design reviews: reviewers can point to a specific guideline instead of arguing about taste.
• Acceptance: wording, message handling and accessibility guidance give testers concrete criteria.

Example: Alder Manufacturing wants a screen for buyers to review supplier confirmations from Cedar Office Supply. Checking the floorplans first shows that a list report with an object page fits, which settles both the design and the build approach. The SAP Fiori Design Guidelines pay off most when they are consulted before the first mock-up, not after the first complaint.

1. Treating the guidelines as developer documentation. They describe the experience; implementation details live in the SAPUI5 SDK.
2. Designing a custom layout when a floorplan fits. Custom layouts cost more to build and maintain and drift from SAP's own apps.
3. Reading the web edition for a native mobile app. iOS and Android have their own editions.
4. Skipping wording and messages. Labels, empty states and error texts are part of the guidelines, and practitioners frequently report that they are the first thing reviewers flag.
5. Equating compliance with fitness for the task. An app can follow every guideline and still model the wrong steps. Process fit has to be checked separately.

The SAP Fiori Design Guidelines are a shared standard, and they work best when the whole team, not only designers, uses them.