Pasquale+
Open to permanent UX Lead roles
DEEN
Case study 02ASFINAG · Critical infrastructure2025–present

UX quality that holds
in critical delivery.

A tolling platform is being modernized while it still has to work. My job: make decisions clear enough that UX, business, and frontend do not keep starting over.

ChallengeLive delivery. Critical workflows. Many business dependencies.
My roleUX Lead · Senior UX/UI Consultant
Key contributionMade business logic visible, clarified decision spaces, and brought components together.
Outcome & evidenceFewer design loops. More consistent implementation.Observed in day-to-day delivery

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.

ASFINAG case study with tolling platform, workflows, and interface artifacts
Figure 02 — context, system, and impact

01 — The Context

A redesign in live operation has no comfort zone.

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:Not producing even more artifacts. Documenting decisions so that business, design, and frontend build 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

The impact is deliberately phrased as an observation: design feedback became more focused, components were implemented more consistently, and open questions surfaced earlier. The figures above describe program scope, not personal team ownership.

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

Not solving everything. But clarifying the right thing first.

01

Untangle the business logic

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

02

Frame the decisions

Show options together with their consequences, so opinions can turn into a decision that holds.

03

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 not a design quality. It 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.

Working on a similarly complex product?

Let’s talk ↗