Writing · 4 min read
What I learned standardizing UX across 40+ SAP Fiori apps
Forty-plus SAP Fiori apps, built by different teams at different times, started to look and work like one product once four things were in place: one style guide with a reusable component library and accessibility rules, feedback from the people using the apps, UX and accessibility checks written into the release process, and teams trained to own it. The shared library cut design-to-development time by about a third and production UI defects by more than half.
Key idea 1 of 7
Forty apps, forty teams, and nobody measuring any of it
The company ran more than forty SAP Fiori apps across logistics and dispatch, asset health and maintenance, safety and compliance, workforce and HR, analytics and workflow. Each one had been built by a different team at a different time.
Someone in the field might open four of them before lunch and have to relearn the layout every time. Design got pulled in at the end to clean things up, if it got pulled in at all. And no one could say whether any of it was working, because no one was measuring it.
I was the lead UX design consultant for two fiscal years, working with the SAP application manager and general manager, the product owners, the business analysts, the developers and the project managers. What follows is what that work taught me, in the order it taught it.
- Reviewevery app, side by side
- One guide, one librarycolors, type, components, accessibility
- Feedbackfrom the people using the apps
- Checksin the release process, not the wiki
- Ownershipteams trained to run their own
Key idea 2 of 7
Review everything before you build anything
Before any of the bigger work, the apps needed to look and behave like they came from the same company. So the first move was to review all of them: visual hierarchy, form clarity, feedback and alerts, accessibility and contrast, error recovery, readability, down to button alignment.
From that review came one Fiori style guide, covering colors and typography, the core UI elements and the accessibility rules, and one pattern library of reusable components everyone worked from: the progress stepper, the filter bar, the dialog.
Once a button looked like a button everywhere, people could stop thinking about the interface and get on with the job. Designers and developers stopped guessing, too.
The lesson is the order. A library built before the review would have been a fifth version of everything.
Key idea 3 of 7
The teams had never heard from the people using the apps
Most enterprise teams design without ever hearing from the people on the other end of the screen. We added feedback right inside the apps, captured at the moment of use, sat with people during their workday, and tracked where they got stuck.
The day-in-the-life interviews were about workflow: pain points, workarounds, what slows people down, how information moves, where collaboration breaks. The in-app feedback turned what people told us into quick fixes, and closing the loop kept the product teams and the people using the apps talking.
Assumptions gave way to evidence, and the conversation shifted from what should we ship next to what is actually getting in people’s way.
Key idea 4 of 7
Quality is decided between the request and the release
Design quality is decided between the moment a request comes in and the day the app ships. We added UX and accessibility checks at every step in between, so quality was not something bolted on at the end.
That is the difference between a standard and a document. The standards stopped being a document and started showing up in every release.
Key idea 5 of 7
Tools and standards do not change a culture on their own
We ran design thinking workshops on usability, accessibility, visual design, information architecture, performance and adoption. We told the stories of what was working, which built awareness and credibility faster than any guideline. And we gave teams a product health scorecard so they could run their own UX checks and see where to improve.
It became normal to talk about user experience the same way teams already talked about uptime or revenue. UX went from someone else’s job to a shared craft.
Key idea 6 of 7
A third off build time and half the defects, once it was used
- 40+
- applications under one design system, hundreds of one-offs replaced by a small library
- ⅓
- off the average time from design to development
- >½
- fewer UI defects in production, quarter over quarter
- ½
- the new-user training time, with real annual savings in support and onboarding
- +20
- NPS, from changes made on user data, across several release cycles
True design is not only about pixels. It is about the system that produces them. And it kept working after I left, which is the only number I would put first.
Key idea 7 of 7
Start with the inventory, and write the checks into the release
Start with the inventory, side by side, before anyone builds a component. Write the checks into the release process rather than the wiki. Pick the two or three numbers that will say whether it is working, and start counting in the first quarter, not the last.
And one thing that was not true when this work was done: the AI tools your teams now build with read the system too, and they cannot ask the person who settled which of two components is the right one and never wrote it down. The legibility that helped forty teams is now what decides whether an agent builds the right thing.