Skip to main content

SAP Fiori — the User Interface of S/4HANA

SAP Fiori is SAP's design system and user interface — role-based, browser- and mobile-capable, and the standard in S/4HANA. It replaces the transaction-driven SAP GUI with task-oriented apps, and it is the most visible difference an end user notices when a company moves from ECC to S/4HANA.

The concept

The classic SAP interface organized work by module and transaction code: a user learned that VA01 creates a sales order and MM03 displays a material, and expertise partly consisted of knowing the codes. Fiori inverts this. Users open a launchpad showing tiles for the tasks their role actually performs, each tile a self-contained app that does one thing and shows the relevant data.

Technically the apps are built on SAPUI5 and HTML5, communicating with the back end through OData services. That architecture is why the same app renders on a laptop and a phone, and why the interface layer can evolve without the underlying business logic changing.

The design principles

SAP names five: role-based (each user sees their tasks, not the whole system), simple (one app, one job), coherent (the same interaction patterns everywhere), adaptive (one app across devices) and delightful — the last of which is marketing language for the observation that an interface people do not resist gets used correctly more often.

Fiori versus the classic GUI

AspectSAP GUISAP Fiori
Operationtransaction codestask-oriented apps
Platformdesktop clientbrowser, mobile
Entry pointEasy Access menuFiori Launchpad
Audiencetrained power usersall roles, including occasional users
Analyticsseparate reportsKPIs embedded in the app

What it means for a project

Two things are worth planning for. First, the launchpad is only as good as the role design behind it: a user who sees eighty tiles has the old problem in a new layout, and getting to the right dozen per role is configuration work that tends to be underestimated. Second, adoption splits by user type. Occasional users gain immediately; long-time power users lose speed before they gain it, and telling them the new interface is better rarely helps. Showing them the embedded analytics they previously had to run as separate reports usually does.

For companies evaluating S/4HANA, Fiori is neither a reason to buy nor a reason to hesitate — it is the interface that comes with the platform. The decisions that matter sit elsewhere, in the selection process and in the migration approach.

Related topics

Frequently asked questions

Does Fiori fully replace the SAP GUI?

For everyday transactional work in S/4HANA, largely yes. For deep configuration, certain administration tasks and some older functionality, the classic GUI is still the tool — and SAP continues to make it available. In most S/4HANA landscapes both exist: business users work in Fiori, the team maintaining the system moves between the two.

Do Fiori apps require additional licensing?

The standard apps are included with the underlying S/4HANA licenses; you are licensed for the functionality, not separately for its interface. Where costs appear is infrastructure and effort — a front-end server or embedded deployment, plus configuration and role work to make the launchpad show each user the right apps.

Can Fiori apps be customized?

Yes, at several levels. Adaptation lets you hide fields and rearrange layouts without code. SAP Build Apps and SAPUI5 development allow entirely custom apps against the same OData services. The trade-off is familiar: adaptation survives upgrades comfortably, heavily customized apps carry maintenance.

How much retraining does a move to Fiori require?

Less for occasional users, more for power users — which is the opposite of what most project plans assume. Someone who enters a few requisitions a month finds the task-based apps easier than transaction codes. Someone who has run VA01 for fifteen years is measurably slower at first and needs a reason to switch, not just a rollout email.