Every Fiori app looks and behaves a certain way — consistent navigation, similar page structures, familiar interaction patterns. That's not an accident of shared components. It comes from five design principles that every Fiori app is supposed to embody. Whether you're building, buying, or just evaluating Fiori apps, these principles are the yardstick.
Here they are, with what each one actually demands in practice.
1. Role-based: built for the job, not the database
Traditional enterprise software exposes the system's structure: transaction codes organized by module, screens that mirror database tables. Fiori flips this. Apps are designed around roles — the purchaser, the warehouse worker, the sales manager — and each role gets exactly the apps, data, and actions their job needs.
In practice this means the launchpad shows different tiles to different users, driven by role assignments. A warehouse worker sees stock overview and goods movement apps; they never see the finance closing cockpit. It's not just hiding menu items — the apps themselves are scoped to the role's tasks, with irrelevant fields and actions simply absent.
The test: can you describe who the app is for in one sentence, and would someone outside that role find it useless? "Approve purchase requisitions for cost center managers" passes. "Maintain business partner master data (all views)" doesn't — that's a database table with a UI, not a role-based app.
Role-based is the principle the others serve. If an app tries to serve every role, it serves none well — it becomes the monolithic transaction Fiori was created to replace.
2. Adaptive: one app, every device
Adaptive means the app reshapes itself for phones, tablets, and desktops — not three apps, not a "mobile version," but one app that responds to its container. The FlexibleColumnLayout collapsing from three columns to a single drill-down on phones is the textbook example. So is the DynamicPage header that snaps shut on scroll to preserve viewport space.
This goes deeper than layout. Adaptive covers input methods (touch targets sized for fingers, keyboard shortcuts for desktop power users), density (cozy mode on touch devices, compact where mouse precision allows), and information priority (the phone shows the three critical fields; the desktop shows all twelve).
The common failure: an app that's technically responsive — nothing overlaps at 375 pixels — but unusable, because the primary action is buried three scrolls down. Adaptive isn't "it renders." It's "the task is still completable."
3. Coherent: familiar everywhere
Coherent means a user who learned one Fiori app can operate the next one. Same navigation patterns, same filter bar behavior, same message handling, same terminology. The List Report in procurement works like the List Report in sales — because it's the same floorplan driven by the same rules.
This is where Fiori Elements earns its keep: floorplans enforce coherence structurally, not just by convention. But coherence extends beyond controls. It covers language (the i18n bundles use consistent terms — "Save" always means save, never "Store" or "Persist"), icons (the SAP icon font, used with consistent meaning), and flows (draft handling works the same in every transactional app).
For custom freestyle apps, coherence is a discipline, not a default. It means reusing the floorplan patterns even when hand-building, following the Fiori design guidelines, and resisting the urge to invent a novel navigation scheme because it seemed clever in a workshop.
Coherence compounds. Each coherent app makes the next one easier to learn; each incoherent one taxes every user who touches it. It's the principle with the highest organizational ROI and the least visible individual credit.
4. Simple: one task, minimal chrome
Simple is the famous "1-1-3" rule: one user, one use case, three screens maximum. A Fiori app does one thing. Not a module, not a process end-to-end — one task. "Approve leave requests." "Create a sales order." "Check stock levels."
Simplicity shows in what's removed: the twenty fields the role never touches, the three tabs for edge cases, the configuration options that belong in a different app. The launchpad model supports this — instead of one monster app, you ship five focused ones and let roles compose them.
It also shows in defaults. A simple app pre-fills what it can, picks the sensible default, and asks only for what's genuinely unknowable. Every field the user must fill is a small tax; simplicity minimizes the bill.
The tension: enterprise reality is complex, and "simple" can feel like "dumbed down" to experts who live in the system eight hours a day. The answer isn't to cram complexity back in — it's the right app for the right role. The expert gets their dense analytical app; the occasional user gets their three-screen flow.
5. Delightful: the details that earn trust
Delightful is the principle people skip, and it's the one users feel most. It covers the micro-interactions: the smooth transition when navigating, the toast confirming a save, the empty state that explains what to do instead of showing a blank screen, the loading skeleton that sets expectations instead of a spinner that says nothing.
Delight also means forgiveness. Draft handling that preserves work across sessions. Undo for destructive actions where feasible. Validation messages that say what's wrong and how to fix it, attached to the field, not dumped in a dialog. An app that forgives mistakes feels delightful; one that punishes them feels hostile, regardless of polish.
And it means performance as a feature. An app that responds instantly feels delightful; the same app with a two-second lag on every interaction feels broken. This is why the technical guidance — OData batching, $select to limit payloads, client-side caching — is ultimately a design concern, not just an engineering one.
How the principles work together
They're not a checklist to apply independently — they constrain each other. Role-based scoping enables simplicity. Coherence makes simplicity safe. Adaptive keeps the simple app simple on every device. Delightful is what the other four feel like when they're done well.
When evaluating or designing a Fiori app, run through all five: Who's the role? Does it adapt? Is it coherent with the apps around it? Is it simple — really one task? And do the details feel cared for? An app that passes all five is a Fiori app in more than name.
Bottom line
Role-based, adaptive, coherent, simple, delightful. Five words that decide whether an app feels like Fiori or just looks like it. The principles are easy to quote and hard to practice — especially simplicity, which demands saying no to features. But the apps users actually love are the ones where all five hold.