Fiori UX in 2025: Still Fighting the Same Battles
Why enterprise UX is stuck and what it takes to fix it
Her name was Maria and she processed 80 goods receipts per hour in the old SAP GUI. She knew every transaction code, every field tab order, every keyboard shortcut that shaved two seconds off a repetitive step. Her muscle memory was faster than most people's deliberate thought. On go-live day we gave her the Fiori Goods Receipt app. It took her 45 seconds to find the app on the launchpad. Another 20 to understand why the vendor filter wasn't behaving the way she expected. By end of day she was at 35 receipts per hour and threatening to go back to MIGO.
Before Fiori — SAP GUI
After Fiori — Week 1 of Go-Live
Maria was not confused. She was not resistant to change. She was a power user being slowed down by a UI that had never been tested on her hardware. The Fiori launchpad had been designed on a consultant's laptop at 1440p, demoed to the CIO on a laptop at 1440p, and signed off by a steering committee who had never run a goods receipt in their lives. On the warehouse terminal — 1024x768, resistive touchscreen, shared with four other workers — the tile layout broke. The search bar wasn't prominent enough. The app grouping made sense to the functional consultant who configured it, organized by SAP module, not by the sequence of things Maria actually did between 6am and 2pm.
We went live anyway. That's the part that stays with me.
The Incentive Gap — Why This Keeps Happening
The gap between consumer and enterprise UX isn't a talent problem or a technology problem. It is an incentive structure problem, and it is baked in deep enough that awareness alone doesn't fix it.
- Demo runs clean on a MacBook at 1440p
- All SAP modules covered in scope
- Vendor support contract in place
- Feature checklist signed off
- UAT green — project can close
- Fewer clicks to complete a goods receipt
- Works on the 1024x768 warehouse terminal
- No training required — I have 300 tasks today
- Same speed as the old system on day one
- Tiles named after what I actually do
Consumer software lives or dies by the user experience because the user is the buyer and the user can leave. Every friction point is a churn risk. Product teams feel it in retention metrics within weeks. Enterprise software has a completely different feedback loop: the procurement team evaluates the feature list, the CIO signs the license, and the user has no exit option. When your job requires SAP, you use SAP. The vendor gets paid regardless of whether Maria's throughput collapses on go-live day.
This creates a rational incentive to optimize for the demo, not the day. The CIO's demo is on a laptop, in a conference room, running a single clean scenario with master data that was set up specifically for the demo. It will never surface the 1024x768 tile breakage. It will never reveal the 45-second launchpad search. The demo looks great. The deal closes. The users pay the bill six months later.
The second layer of the problem: Enterprise implementations have too many stakeholders with design veto power. The IT team has security requirements. The business process owner has workflow preferences. Finance wants their GL accounts visible at all times. Operations wants their storage locations front and center. Basis wants the configuration to be maintainable across upgrades. Every one of these stakeholders can block a UX decision. The result is a launchpad that satisfies every requirement on a checklist and nobody's actual working day. The user sits at the intersection of everyone else's constraints and nobody's advocacy.
The deeper problem is that the people with the most design influence — functional consultants, solution architects, project managers — experience Fiori at 30 minutes per task, not 300 transactions per day. They evaluate it as a first-time user discovering features. Maria uses it as a production worker for whom every extra click is a measurable cost. These are completely different UX problems, and the first one gets solved while the second one gets ignored until go-live.
"Enterprise software optimizes for feature completeness, not task completion. The buyer evaluates the feature list. The user experiences the task flow. These are different things, and the person who signs the license agreement has never run a goods receipt."
And there is no corrective feedback mechanism. Consumer apps have crash reports, funnel analytics, session recordings, and NPS scores that feed back to the product team within days. Enterprise Fiori implementations have a UAT sign-off document, a go-live readiness checklist, and a hypercare period that ends 30 days after launch. By the time Maria's throughput collapse shows up in operations metrics, the project team has rolled off and the system integrator has closed the engagement. The incentive to care about post-go-live UX performance simply does not exist for the people who made the design decisions.
What Fiori Actually Does Well
This is not a post about Fiori being bad. Fiori is the right direction. The problem is that the right direction, implemented wrong, can be worse than standing still.
Role-based app delivery is the strongest genuine Fiori capability, and I've seen it work well exactly once in a way I'd hold up as a model. A distribution client, mid-size, had three distinct warehouse roles: receivers, pickers, and returns processors. Instead of giving every warehouse worker a 40-tile launchpad with everything from inventory reports to material master maintenance, the project team spent two days interviewing six workers — two from each role — and mapping their actual daily task sequences. The result was three launchpads. Receivers got five tiles. Pickers got four. Returns processors got six. Every tile was named as a verb. "Receive Delivery." "Check Open POs." "Log Discrepancy." No module names. No transaction codes. No tiles that existed because someone in the steering committee said "we might need it."
Launchpad Design — The Classic (What Ships)
Launchpad Design — Task-Based (What Works)
That deployment went live without a productivity collapse. Maria's deployment did not. The difference was not the technology. The difference was two days of user interviews that most projects never budget for.
OData alignment for mobile is the second real Fiori strength. The REST-based OData services that power Fiori apps are architecturally cleaner than BAPI/RFC-based integration — cacheable, mobile-compatible, and far more composable for extension scenarios. Building on OData is the right foundation. The implementation layers above it are where the problems accumulate.
The Three Patterns That Actually Work
Task-based launchpad design. The standard implementation groups by SAP module because the functional team that configures the launchpad thinks in modules. The right approach: interview three users per role and ask them to describe their day in sequence. "I come in, I check what deliveries are expected, I process the ones that arrived, I handle the discrepancies." Map the launchpad to that narrative. App names should be verbs, not nouns. "Check Expected Deliveries" is a job task. "VL06I - Inbound Delivery Monitor" is a database reference. One of those belongs on a warehouse launchpad.
Progressive disclosure before UAT. Identify the top 10 fields users actually populate in 90% of transactions. Hide everything else behind a "More" expansion. Test with three real users — not super users who know SAP, but people who will use it on the production floor on day one — and watch where they hesitate. If someone searches for a field that's hidden, surface it. If nobody notices a field is hidden across 20 runs, it belongs hidden permanently. The business will insist every field is mandatory. Field usage data will say differently. Trust the data.
Hardware-first testing. The launchpad that renders beautifully on a consultant's MacBook may be completely unusable on the device the actual user has. Test on the hardware before UAT, not after. Warehouse terminals at 1024x768. Shared tablets with cracked screen protectors. Industrial touchscreens with 40ms input lag. Network latency on the warehouse floor versus the conference room. These variables exist. They are not visible from a laptop in a meeting room. If you cannot get physical access to the production hardware before UAT sign-off, your UAT is not testing what it thinks it's testing.
The One Thing UX Designers Miss About Enterprise Context
Consumer UX optimizes for discoverability. New users need to find features intuitively. Enterprise UX should optimize for throughput. Maria is doing the same task 300 times per day. After week two, discoverability is irrelevant — speed and muscle memory are the entire user experience.
This means keyboard navigation in Fiori apps matters more than most implementations treat it. The field tab order in a goods receipt app should follow the physical flow of processing a delivery — vendor first, then PO number, then material, then quantity, then storage location. If the tab order follows the database schema instead of the physical process, you have added friction to 300 transactions per day per user. That friction is measurable and it is entirely self-inflicted.
It also means that the UI optimized for a first-time user during UAT testing is not the same UI that serves a power user in week six of production. These are different design problems. Most Fiori implementations solve the first one and ignore the second. The result is a system that passes UAT and fails Maria.
The Two-Minute Test
The Two-Minute Test
Give a non-SAP user two minutes. Hand them the production device. Ask them to complete the most common daily task from a cold start — no guidance, no hints, no training deck. Count every click.
A user observation session before UAT. Not a survey. Not a feedback form. Someone sitting next to a real user — on production hardware, on the warehouse floor — watching them try to complete their daily task. The hesitations, the wrong clicks, the moments where they look around for a field that moved, the point where they give up and ask a colleague — these are invisible in any other feedback mechanism. One afternoon of observation identifies more real UX problems than three weeks of functional testing. It almost never happens because nobody budgets two days and a plane ticket for something that doesn't appear on a project milestone chart.
Maria eventually got fast on the Fiori app. It took six weeks. In those six weeks, her team processed 30% fewer goods receipts than the production plan called for. That shortfall caused a backlog in goods movements. The backlog in goods movements caused a backlog in production orders. The backlog in production orders caused a very uncomfortable conversation in the weekly operations review, where a VP asked why the warehouse team was underperforming. Nobody in that meeting mentioned the launchpad tile layout. Nobody connected it to the 1024x768 screen that had never been tested. The warehouse team absorbed the blame for a design decision made six months earlier by people who would never run a goods receipt.
All of it — the six weeks, the 30% shortfall, the operations review — was preventable with one afternoon of hardware testing before go-live.
The UX decisions that get made last — launchpad configuration, field visibility, tile grouping, tab order — determine what the first six weeks of production look like for every person on the warehouse floor. Treating those decisions as cosmetic concerns rather than operational risk is the mistake I would go back and fight harder against. I didn't fight hard enough on that one. Maria paid for it.