Fleet platform

The company behind the project runs one of the world's largest fleet-digitalization ecosystems: millions of connected vehicles across 160+ countries, thousands of partner companies and device types.

Two products, two speeds, one design team covering both: a flagship carrying two decades of interface history, and a next-gen platform heading to public launch. A product this capable deserves an interface that communicates it — raising the design quality to match the engineering underneath was the opportunity the launch created.

It is also a B2B2B product, which shapes every decision. The platform is sold through partners, operated by fleet businesses, and used daily by managers and operators whose goals don't align neatly: the reporting a fleet owner wants can be exactly the data entry that slows down the person in the depot. Most design decisions here are a trade-off between business objectives, operational efficiency, usability and what the platform can technically support.

• A fixed launch date — design quality and delivery had to move together, at pace.
• Two decades of accumulated patterns — tables, modules and conventions built up over the flagship's lifetime.
• Fragmented design practice — new features started in separate files and parallel libraries grew alongside them, so no single source of truth existed for either designers or engineers.
• Users a step removed — sold through partners and operated by their customers, so validation had to be assembled rather than simply asked for.

Responsible for improving the product experience across both products while establishing the design practices that let it scale — leading the design team at full design load, hands-on throughout.

I own the product experience across both products — the new platform and the 20-year flagship — along with the audit backlog, the research practice and the design system underneath them. The role reaches past design too — working across product definition and requirements with product management and business analysis, and running design review after development, not only before it.

• The product experience across both products — flows, architecture and interaction, end to end.
• Pre-release UX/UI audit → prioritized quality backlog.
• Research — usability tests, IA surveys, competitive analysis.
• The design foundation — one reference library and the process that keeps it current.
• Design leadership & hiring — directing and supporting the team, and growing it.

A full pre-release UX/UI audit of the new platform — hierarchy, navigation, tables, states, iconography.

Every finding framed as Problem → Solution and turned into a working quality backlog, prioritized with product and engineering. The same discipline was then applied to the 20-year flagship and its legacy UI.

• Confirmed "was → now" fixes shipped in production.
• Legacy product audited into a prioritized improvement backlog.
• WCAG 2.1 AA adaptation of the library ahead of the European Accessibility Act.

As the platform grew, design practices had spread out: new features started in new files, and parallel libraries appeared alongside them. I rebuilt the foundation — components, tokens and the process governing both — so consistency stopped depending on who remembered what.

Foundations first: typography, colour, spacing, shadows, radius and icons defined as a token layer, with contrast and accessibility checked at that level rather than per screen. Components were then rebuilt on top, so a fix to a foundation propagates instead of needing to be found in six places.

Fewer libraries was only half of it. The other half was making the system findable and current: one predictable structure for Figma projects and files, mockups kept in step with what has actually shipped, and a defined process for how the library gets updated and versioned — so "the current design" is one unambiguous thing anyone can reach, designer or engineer.

Storybook aligned with Figma and the Figma project structure rebuilt around it, so design intent and implementation stay in step. The library is WCAG-adapted and machine-readable: token exports and rules files let AI agents assemble screens from real components rather than lookalikes.

• One source of truth — seven parallel libraries replaced by a single reference library shared by design and engineering.
• Project & file structure — one predictable place for everything, so the live design is easy to find.
• Mockups kept current — updated as work ships, so the source of truth stays true.
• Library governance — a defined process for how patterns get added, changed and versioned.
• Storybook ⇄ Figma alignment.
• Tokens + rules for the AI-assisted workflow.
• Accessibility built in, not patched on.

Across both products the work isn't divided into private territories — the design library runs through every module, so I'm accountable for how the whole surface behaves rather than for a list of screens.

That makes information architecture the first decision, not the last. Map the structure properly and a new module has an obvious place; get it wrong and every addition renegotiates the navigation. Concepts get tested before they reach development, so the structure is argued from evidence rather than from whoever framed it first.

In a B2B2B setup, direct access to the people using the product daily isn't a given — they work for someone else's company. So validation comes from several directions at once rather than one interview round: moderated testing on real prototypes, partner and stakeholder insight, product data, and feedback collected through a documented process instead of ad hoc.

• Information architecture mapped across the platform, so flows are specified against a known structure.
• Moderated usability tests on real prototypes — facilitator / notetaker protocols, A/B prototype rotation.
• IA & survey research and competitive navigation analysis.
• Interactive prototypes generated from Figma and used in live sessions instead of static mockups.

Two products scaling at once, in startup mode: the way of working has to be built while the product ships. So I wrote the practices down as we went — and I'm still writing them.

Documentation is the deliverable that outlasts any screen. Design guidelines, explicit decision ownership, a Definition of Done that covers the unglamorous states, review practices that carry quality through delivery, and enablement material so engineering can work from the system directly rather than from a hand-off.

Testing became a routine rather than an event — moderated protocols and A/B prototype rotation set up as something the team can repeat without me running every session.

• Design guidelines & documentation — a living reference for patterns, states and usage, maintained alongside the library rather than after it.
• RACI for design decisions — explicit on who decides, who is consulted and who is informed, so ownership doesn't have to be renegotiated per task.
• Definition of Done for design — all component states, empty / error / loading, edge cases, adaptive behaviour, copy and validation.
• Review practices — design review before build and again after it, keeping intent and implementation aligned.
• Enablement for engineering — guidelines and training material so the team can build from the system directly.
• Repeatable testing — facilitator / notetaker protocols and A/B prototype rotation, documented as a routine.