Back to home M

Nederlandse Spoorwegen.

OV Pay: from complex systems to clear interactions.

OV-pas introduction Logic modelling Systems design

RoleUX & systems design · research
ScopeLogic modelling · dynamic form states · WCAG / EAA
TeamNS Flex · Translink · dev teams
Year2025
Project cover — hero image / product shot

01 The challenge

Simple screens,
complex logic.

The new OV-pas changed how the NS Flex webshop interacts with NS account data and third-party systems. Behind a seemingly simple checkout, the flow had to respond to customer states, missing data, verification steps and product rules.

My challenge — turn complex system logic into screens customers could understand and developers could build.

02 Context

Hidden complexity.

Each checkout step is shaped by user state, account data and business rules — while NS and Translink data can fall out of sync. Multiple internal teams and external parties were involved without central guidance, and definitions kept evolving.

Systems diagram — data sources & dependencies
Mapping where account, OV-pas and Translink data meet.

03 Process

From requirements
to customer tasks.

Before designing UI, I translated technical and business requirements into a task model — a visual aid for the right order of steps, the data needed at each moment, and where paths start to branch.

Task model — requirements → customer tasks

04 Alignment

Creating a single source of truth.

I refined these logic charts to align stakeholders and dev teams around one shared understanding — connecting API docs, business decisions and frontend behaviour into a clear picture of how the webshop should respond to each system state.

Logic chart — system states & frontend behaviour (wide)
One chart connecting API documentation, business rules and UI.

Placeholder — a stakeholder or developer quote validating that the logic charts became the team's shared reference.

— Placeholder name, role · NS Flex

05 The solution

One form, many system states.

The data step is the most dynamic in the checkout. Based on account state, OV-pas state, product type and Translink data, the form decides which fields to show, what can be edited, and when verification is required.

Data step — dynamic form (annotated UI screen) 1NS account data 2Translink data 3Product-specific rules 4One-time-password verification
Fields, edit-ability and verification adapt to the underlying system state.
Full-bleed image — final screens / detail shot

06 Outcome

Designing clarity.

By mapping dependencies, aligning teams and charting system logic, I helped make the webshop understandable for customers and actionable for development.

40+checkout states mapped
4teams aligned on one source of truth
100%WCAG 2.1 AA compliance