Explain SAP Fiori Design Principles & Fiori Elements in SAP

31 / 65

S/4HANAbeginner

SAP Fiori Design Principles & Fiori Elements

SAP's modern UX approach: role-based, responsive, simple, coherent design and the Fiori Elements floorplan templates.

Fiori questions are the entry point to nearly every S/4HANA UI conversation, and interviewers ask about the underlying design principles - not just "what does Fiori look like" - to see if a candidate understands why SAP moved away from SAP GUI's transaction-dense screens toward a fundamentally different UX philosophy.

Fiori Elements is like ordering a custom suit from a tailor's standard pattern book by giving your measurements (CDS annotations) rather than sewing every seam by hand (freestyle UI5) - you get a well-fitting, consistent result far faster, reserving fully bespoke tailoring for the rare cases the pattern book genuinely can't cover.

Key Concepts

SAP's five Fiori design principles are role-based (an app is scoped to what one specific persona needs to do, not a monolithic transaction trying to serve everyone), responsive (one app adapts across desktop, tablet, and phone rather than requiring separate mobile builds), simple (focused on the 20% of functionality covering 80% of daily use, with the rest reachable but not front-and-center), coherent (a consistent visual language and interaction pattern across every app, so learning one app transfers to the next), and delightful (genuinely pleasant to use, not merely functional). This is a deliberate contrast to classic SAP GUI transactions, which tend to expose every field and option a power user might ever need in one dense screen.

Fiori Elements is the floorplan-driven approach to building these apps without writing custom UI5 view code for standard patterns: List Report (a filterable, sortable table of items - the most common floorplan), Object Page (a detail view with sections for one specific record), Overview Page (a KPI/card-based dashboard), and Worklist are metadata-driven, meaning the actual screen layout is generated at runtime from OData service annotations rather than hand-coded XML views - a massive productivity difference from freestyle SAPUI5 development where every screen is built by hand.

A senior-level answer distinguishes Fiori Elements (fast, low-code, ideal for standard CRUD-style apps, driven entirely by CDS view annotations like @UI.lineItem and @UI.facet) from freestyle SAPUI5 (necessary for highly custom or complex interactive UIs Fiori Elements can't express), and mentions the Fiori Launchpad as the unifying entry point that aggregates tiles/apps from potentially many different backend systems into one coherent, role-based home page for the end user.

@UI.lineItem@UI.facet