Fleet operations at national scale

A multi-product platform for managing a national fleet, four products, three designers, 900 operational users.

User flows for preventive maintenance and repair, with swimlanes for booking, reception, and supervisor. — Fig 01 User flows for preventive maintenance and repair, swimlanes split by role.

Flows that match how the work happens

Once the architecture was settled, we drew flows for the two transactions that drove the platform's value, preventive maintenance and repair. These were not happy-path flows. They captured the agency exceptions, supervisor approvals, and multi-side handoffs between booking, reception, and the workshop.

Designers and engineers shared the same flow file. Operations reviewed it before any UI was made. By the time a screen got drawn, the argument about "what should happen here" was already settled.

The tradeoff that shaped the design

Density against approachability. Operational users want every piece of information on one screen. New users want one decision at a time. We resolved it with role-based density, the same data model presented differently per role. Inspectors got dense tables with inline editing. Senior management got summary dashboards. One backend, one component library, two surfaces.

Design system for the fleet platform, components, color, typography, controls, tabs, and domain patterns on a single board. — Fig 02 The shared design system, components, colour, type, controls, and domain patterns on one board.

One design system, four products

The design system was not optional. With three designers, four products, and a multi-year backlog, the only way to stay coherent was to build the components, tokens, and patterns first, then assemble screens from them.

The system covered colour, type, controls, tables, filters, tabs, status pills, and the agency's domain-specific patterns, asset chips, role-based density, status workflows. Anything that recurred more than twice became a token or a component. Everything else stayed a one-off and got reviewed as such.

Outcomes

Four products shipped on a shared design system, used daily by around 900 operational staff across inspection, workshop, dispatch, and fleet management.
Fleet utilisation up around 20% once dispatch and workshop status shared one model.
Around 20% saved on procurement after the platform exposed real asset availability before new purchases were approved.
Vehicle booking down from around 15 minutes to around 2 minutes.
Around 40% less development time across the four products, built from one component library instead of three codebases.
Around 30% lower build cost as a result of that shared system.
Cross-product navigation time reduced after the unified information architecture replaced the previous three-system patchwork.
Time-to-onboard new operational hires dropped because patterns repeated across products.
Design-engineering pairing time shrank as the component library matured, more screens from the same primitives.

Caveat: directional figures based on internal benchmarks. Exact numbers under government NDA.

A moment of "this works".

The platform is the design system

At this scale, the platform is the design system. Screens are throwaway. Tokens, patterns, and role-density rules are what actually compound. Three years on, the original screens have been redrawn. The system is still the system.