Fiori UX in 2026: Still Fighting the Same Battles
Why enterprise UX is stuck and what it takes to fix it. The story of Maria, the 1024x768 warehouse terminal, and the design decisions that cost six weeks of throughput.
The terminal at Receiving Station 3 was a Panasonic Toughpad, 1024×768, screen protector cracked in the lower left corner from a forklift near-miss in 2023. Maria stood in front of it at 6:47am, coffee steaming beside the barcode scanner, and tapped the Fiori launchpad tile labeled "Inbound Delivery Monitor — VL06I."
Nothing happened. Well, something happened — the OData service spun, the loading spinner appeared, the screen painted itself in SAP's standard blue, and then the filter fields loaded. But the work didn't happen. Maria knew this screen. She'd done this 1,200 times. The filter defaulted to "Plant: All" instead of her plant. The "Delivery Date" field defaulted to today instead of yesterday's outstanding deliveries. The "Status" dropdown defaulted to "Open" when she needed "Partially Processed." Three manual adjustments before she could see the one delivery that had been sitting on the dock since 11pm.
This was not a bug. This was the design. The launchpad had been configured by a functional consultant who'd never run a goods receipt, on a MacBook Pro in a conference room, using a 1920×1080 monitor, with the warehouse manager's "requirements document" as the only user input. The warehouse manager hadn't run a goods receipt since 2012.
Six weeks later, Maria was fast. She'd memorized the three clicks to fix the filters, the tab order workaround, the keyboard shortcut to skip the vendor field that always auto-filled wrong. Her throughput was back to baseline. But in those six weeks, her team had processed 30% fewer goods receipts than the production plan called for. That shortfall cascaded — goods movements backed up, production orders stalled, a VP asked uncomfortable questions in the weekly ops review, and the warehouse team absorbed the blame for a design decision made six months earlier by people who would never scan a delivery.
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.
The buyer — CIO, program manager — sees a clean demo 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.
The user — Maria, warehouse — sees fewer clicks to complete a goods receipt. Works on the 1024×768 warehouse terminal. No training required — she has 300 tasks today. Same speed as the old system on day one. Tiles named after what she actually does.
Zero overlap in priorities. The buyer never sees what the user sees. The user has no exit option.
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 set up specifically for the demo. It will never surface the 1024×768 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.
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.
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 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.
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."
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 1024×768. 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.
| Check | Pass Criteria |
|---|---|
| Cold start task completion | Non-SAP user completes most common daily task in <2 minutes, no help, first try, on production hardware |
| Tile naming | All tiles grouped by job task, every label is a verb describing what the user does |
| Hardware validation | ≥3 real end users (not super users, not consultants) tested on production hardware before UAT sign-off |
What Most Fiori Implementations Are Missing
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 1024×768 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.
Stay with us · poll
What do you think is the biggest challenge in improving SAP Fiori UX?
Share your thoughts on what stands in the way of better user experience with SAP Fiori.
No account needed — pick a take, then keep reading. We rotate these prompts so each piece feels like a conversation, not a clone.
