What I learned standardizing UX across 40+ SAP Fiori apps

Key idea 1 of 7

Forty-plus apps, built by different teams, and nobody measuring any of it

The company ran more than forty SAP Fiori apps. They covered logistics and dispatch, asset health and maintenance, safety and compliance, workforce and HR, and analytics and workflow. Each 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 came in at the end to clean things up, if 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. I worked with the SAP application manager and general manager, the product owners, the business analysts, the developers and the project managers.

Underneath was one question: how do many teams, building at different times, inherit the same design decisions? Each move below is a different answer.

1. Reviewevery app, side by side
2. One guide, one librarycolors, type, components, accessibility
3. Feedbackfrom the people using the apps
4. Checksin the release process, not the wiki
5. Ownershipteams trained to run their own

Key idea 2 of 7

Review everything before you build anything

Before any 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, down to button alignment:

• Visual hierarchy
• Form clarity
• Feedback and alerts
• Accessibility and contrast
• Error recovery
• Readability

That review produced one Fiori style guide: colors and typography, the core UI elements and the accessibility rules. It also produced one pattern library of reusable components, such as the progress stepper, the filter bar and the dialog. Everyone worked from both.

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

Most teams design without hearing from the people using the apps

We added feedback right inside the apps, captured at the moment of use. We also 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. 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

We added UX and accessibility checks at every step between the request and the release, so quality was not bolted on at the end.

That is the difference between a standard and a document. A document is inherited by whoever reads it. A check in the release is inherited by every team that ships, including the ones that never opened the guide. The standards 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. We also 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

About a third off design to development, and roughly half the UI defects, as the program ran

40+

applications under one design system, in place of hundreds of one-off components

⅓

off the average time from a design marked ready to development starting on it

½

fewer UI defects in production, roughly, counted per quarter

½

the new-user training time, by the training team’s own count

+20

NPS, roughly, from the in-app survey across several release cycles

These moved while the program ran. They are counted from the teams’ own trackers, not a controlled experiment, and nothing here isolates the design system as the only cause.

The design-to-development figure compares two quarters before the shared library with two after it. Story size was not normalized. Releases got smaller over the same stretch the defects fell.

The training figure is the training team’s. So is the estimate of what it saved, which I did not audit. The survey had modest responses per release, so the NPS change is read across releases, not from any one. The case study sets out how each was counted.

The pixels mattered, but what lasted was the system that produced them. It kept working after I left, which is the result 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.

One thing was not true when this work was done. The AI tools your teams now build with read the system too. They cannot ask the person who settled which of two components is the right one and never wrote it down. The legibility that helped the teams inherit the system is now what decides whether an agent builds the right thing.

That is the question I took into Agent Review at a much smaller scale. The setup was a React component system, the rules a coding agent reads, and one feature request run with those rules and without them. Both runs stayed inside the system, which says more about the components and the tokens than about the rules.

It is one experiment on one system, not a program. It asks what the Fiori work asked, with a different kind of team on the other end.