ASFINAG case study

Measured means the figure comes from a documented survey inside the project. Observed means the change was visible in everyday work but was not formally captured.

01 — The Context

Rebuilding while the system runs.

Around 80 operational specialist users work in an environment where mistakes are not merely annoying. At the same time a large program keeps moving. UX has to provide orientation here without slowing delivery down.

The context:40 to 60 participants in the program context, complex roles, and a platform that cannot simply be paused.

The real task:Documenting decisions so that business, design, and frontend end up building the same thing.

02 — The Impact

Less room for interpretation. More shared direction.

~80operational specialist users

40–60participants in the program context

1shared component logic

Observed, not measured: design feedback became more focused, components were implemented more consistently, open questions surfaced earlier. The figures above describe the program, not my team.

Artifacts from a live infrastructure program are confidential. Public artifacts are limited by confidentiality; anonymized flows and component examples can be discussed in a direct conversation.

Schematic: above, domain, design and frontend build the same decision in three variants; below, all three converge on one documented component logic. — One decision, three readings — and the shared foundation after

03 — The Approach

Clarify the right thing first.

Decision: modernize the existing system.

Starting point: There already was a design. Built on PrimeNG, but basic: not responsive, hardly modern. The business side thought it was a prototype. The frontend rebuilt every screen one by one, so any change to the system had to be copied into every screen by hand.
On the table: A radical redesign: heavily simplified, self-explaining, with one cross-cutting search as the entry point.
A move to a more modern, more flexible design system.
Modernize the existing PrimeNG system and turn it into reusable components.
Chosen: The third option, agreed with the frontend lead. A new look, clear hierarchy through headings and intro texts, components that are built once and used everywhere. Most work happens with mouse and keyboard. The system still has to hold up on touch.
Rejected: The data structure behind the platform could not support a cross-cutting search. A system switch and a full UX rework were no longer possible this late: the go-live date was fixed, and the features were set by the service specification.
The trade-off: Table actions are now named in a menu instead of shown only as icons. That costs experienced users one click. New users see right away what will happen.
What changed: Dry runs where the frontend team shows what they built. A regular meeting with the client contact. Visits on site, where the specialist users actually work. Wishes and limits discussed openly.
What didn't work: Merging features. Three functions that could be one are still three. That would have meant renegotiating the service specification, and it was too late for that.

Untangle the business logic

Make workflows, roles, and exceptions visible together. Only then is the jump into the interface worth it.

Frame the decisions

Lay out options with their consequences side by side so the team can decide. There is an example just above.

Make it fit delivery

Describe components, states, and rules so they do not have to be reinterpreted in the frontend.

“In critical delivery, clarity is risk management.”What working on infrastructure changes

04 — Key Learnings

What stayed from this work.

Early questions are cheaper.

When contradictions in a flow become visible before they land in code, that saves more than any late polish.

Consistency needs reasons.

A component name alone convinces nobody. The rule behind it is what makes it hold up day to day.