SAP Fiori is SAP's design system and user experience language for enterprise applications. It defines a set of design principles, predefined page layouts called floorplans, and UI patterns that give SAP business apps a consistent, role-based, and responsive feel across desktop, tablet, and phone. If you have used a modern SAP S/4HANA screen in a browser, you have used a Fiori app.
Fiori matters because SAP's products are vast. Without a shared design language, every module would look and behave differently. Fiori imposes a common UX so that a user moving from finance to procurement to HR encounters the same interaction patterns, the same navigation, and the same visual vocabulary. For developers, it means you do not design an interface from scratch — you assemble it from documented floorplans and controls.
This guide covers what Fiori is, how it relates to the SAPUI5 framework, the main floorplans, and how AI coding assistants fit into Fiori development.
What is SAP Fiori?
SAP Fiori is built on five design principles that distinguish it from older SAP GUI screens:
- Role-based — Apps are designed around a specific business role (purchase manager, accounts payable clerk, maintenance technician) and show only what that role needs.
- Responsive — The same app adapts from desktop to tablet to phone without separate codebases.
- Simple — Each app solves one task well. Complexity is moved out of the UI and into guided flows.
- Coherent — Shared floorplans, controls, and navigation mean users learn one app and understand the next.
- Delightful — Motion, feedback, and accessibility are first-class concerns, not afterthoughts.
Fiori is not a single product. It is a design system realized through several layers: the design guidelines, the SAPUI5 control library that implements them, the Fiori elements templates that generate standard layouts, and launchpad or work-zone experiences that host and catalog the apps.
SAP Fiori vs SAPUI5
The most common confusion for newcomers is the relationship between Fiori and SAPUI5. They are different things that work together:
| Aspect | SAP Fiori | SAPUI5 |
|---|---|---|
| What it is | Design system + UX guidelines | JavaScript UI framework |
| Layer | Conceptual / visual | Technical / code library |
| Defines | Floorplans, principles, look and feel | Controls, data binding, MVC, build tooling |
| Built with | N/A (design language) | JavaScript / TypeScript |
| Relationship | Implemented using SAPUI5 | The framework Fiori apps are built on |
The short version: SAPUI5 is how you build it; Fiori is what it should look and behave like. A SAPUI5 app that follows the Fiori guidelines is a Fiori app. A SAPUI5 app that ignores them is a "freestyle" SAPUI5 app — still functional, but not Fiori-compliant.
Fiori Floorplans
Fiori standardizes on a small set of page layouts called floorplans. Each floorplan is optimized for a common business task, so most SAP transactional apps reuse one of them:
| Floorplan | Best for | Key feature |
|---|---|---|
| List Report | Browsing and filtering collections | Smart filter bar, table, chart toggles |
| Object Page | Viewing and editing a single record | Header, sections, anchor nav |
| Worklist | Processing a queue of items | Compact table, mass actions |
| Analytical List Page | Data exploration with KPIs | Visual filters, chart-first layout |
| Form Object Page | Guided data entry | Responsive forms, field groups |
Most Fiori apps combine a List Report (the overview) with an Object Page (the detail) into a two-level navigation pattern. This consistency is why users can move between unrelated SAP modules without relearning the interface.
Fiori Elements vs Freestyle SAPUI5
When you build a Fiori app, you choose between two abstraction levels, and the decision repeats itself on nearly every SAP frontend project:
- Fiori elements generates the UI from OData annotations and predefined floorplans. You mostly write annotations and a data model, not views and controllers. This is the recommended starting point because it produces consistent Fiori UX with a fraction of the effort, and it automatically picks up features like filtering, sorting, and value helps.
- Freestyle SAPUI5 gives you full control over the UI. You write XML views, controllers, and routing by hand. Use it only when the UI is highly custom and no floorplan fits.
In practice, teams start with Fiori elements and drop into freestyle only where a template cannot express the requirement. The same OData service often powers both.
SAP Fiori Launchpad and Content
Fiori apps do not live in isolation. They are hosted and organized by launchpad or portal experiences such as SAP Fiori launchpad and, in many cloud scenarios, SAP Build Work Zone. These entry points render app tiles or pages for users after login, handle cross-app navigation, and manage role-based visibility. App registration — assigning an app to catalogs, spaces, pages, or roles — is configuration metadata, not code, and it is what makes an app visible to the right users.
Building Fiori Apps with AI Assistants
Fiori development sits at the intersection of design guidelines, the SAPUI5 framework, OData annotations, and the SAP Fiori tooling. That is a lot of overlapping context, and it is exactly where general-purpose AI assistants struggle. Without domain knowledge they frequently invent SAPUI5 control names that do not exist, write OData v2 binding syntax in a v4 context, produce annotations that fail validation, or design layouts that violate the Fiori floorplans.
That gap is what the SAP Skills address. A SAPUI5 skill gives the assistant the current control APIs, manifest patterns, and testing conventions; a Fiori tools skill covers the Page Editor, Service Modeler, and deployment flows. With the right skill installed, the assistant generates code that follows SAP framework conventions instead of plausible-looking but broken patterns.
Recommended skills for Fiori work:
sapui5— the core framework skill. Covers freestyle and Fiori elements apps, custom controls, OData v2/v4 integration, routing, QUnit and OPA5 testing, andsap.ui.mdc.sap-fiori-tools— covers the SAP Fiori tools extensions: Page Editor, Service Modeler, deployment, adaptation projects, and thefiori-mcp-serverfor AI-assisted generation.sapui5-cli— focused on the UI5 Tooling CLI: project init,ui5.yaml, builds, and the dev server.sapui5-linter— covers@ui5/linterrule configuration, autofix, and CI integration.
Install any of them with:
npx skills add secondsky/sap-skills --skill sapui5
npx skills add secondsky/sap-skills --skill sap-fiori-tools
If you are building a full-stack SAP app, pair these with the sap-cap-capire skill so
the assistant understands both the OData producer (CAP) and the Fiori consumer.
Getting Started
- Read the design guidelines at the SAP Fiori design site to internalize the floorplans and principles before writing code.
- Decide between Fiori elements and freestyle SAPUI5. Default to Fiori elements for standard transactional apps; reach for freestyle only when a floorplan cannot express the UI.
- Install the matching SAP Skills so your AI assistant has accurate, current context for the framework and the tooling.
- Use SAP Business Application Studio or the VS Code Fiori tools to scaffold, edit, and deploy your first app.
Fiori rewards consistency. Pick the right floorplan, follow the design principles, and let the templates and tooling handle the repetitive parts — then spend your effort on the data model and the business logic that actually differentiate your app.