Token-Based Design System

Project Overview

Product: TomTom Mobile Navigation App

Scope: iOS & Android design systems

Focus: Tokens, theming, and design–engineering collaboration

The Problem

When we started building TomTom's new navigation app, we inherited two existing design systems: one from GO Ride, which the new product was being built on top of at the code level, and one from TomTom's central UX design system team. Neither was built for the kind of visual flexibility we needed. Component-level token abstraction was only partially implemented, making incremental theming changes painful. More critically, neither system used a token-based approach at the implementation level, meaning any visual change after handoff required significant developer effort to execute. We needed to build something new that could scale, theme, and evolve without creating a bottleneck in engineering every time the visual direction shifted.

My Role & Ownership

Role: Product Designer, Design Systems & Tokens

I owned the Design system, theming strategy, and design-to-engineering handoff, working closely with the central design system team and mobile engineers.

I personally owned:

• Token creation and naming conventions

• Token Studio setup and exports

• JSON handoff pipeline with engineering

• Ongoing system evolution and maintenance

• QA of system implementation across platforms

Goals

• Enable fast UI delivery without locking the product into visual decisions

• Create a system that scales across iOS and Android

• Reduce dependency on developers for routine theming updates

System Architecture

Three-Layer Token Abstraction

We implemented a global → system → component token structure:

• Global tokens: raw primitives (color, spacing, typography)

• System tokens: semantic intent (e.g. warnings, guidance, states)

• Component tokens: localized overrides for specific UI elements

This separation allowed visual changes without breaking component logic or engineering dependancies.

Tooling & Engineering Pipeline

Design → JSON → GitHub

• Managed token exports via Token Studio

• Produced JSON files consumed directly by engineering

• Established a feedback loop where token changes could be reviewed, versioned, and merged with minimal friction

This pipeline allowed design to move quickly without requiring constant developer intervention.

Theming & System Evolution

As the visual direction evolved, I translated approved design decisions into updated token sets and theme definitions, a process made significantly more manageable by the pipeline architecture. Because tokens were abstracted across three layers, visual changes could be applied at the right level without cascading rework through components or breaking engineering dependencies.

These theming exercises also had reach beyond the app. Work we developed toward updating TomTom's overall UI theme, still in progress, fed directly into the central design system team's direction, aligning mobile and broader product surfaces around a shared visual foundation.

AI-Assisted System Maintenance

To manage the scale of token work, I used Claude and ChatGPT to handle bulk edits across JSON files, comparing token sets between versions, catching inconsistencies, and executing changes that would have taken a couple of hours manually in around 20 minutes. It didn't replace the thinking, but it removed the tedious parts of evolving a large token library at speed.

• Perform bulk edits across token libraries

• Compare JSON files between versions

• Reduce manual errors when evolving the system

Impact

The system shipped to production supporting an app that replaced TomTom's legacy navigation product, inheriting 500K existing users and growing to 1M+ in under two months of launch. During that period I ran fast-turnaround UI fixes in response to feedback from the migrating user base, validating that the system was flexible enough to absorb rapid iteration under real pressure.

The token pipeline created a specific and meaningful efficiency gain: because JSON updates were consumed automatically by engineering, designers could iterate on theme and accessibility issues without competing for developer time. Changes that previously required negotiating sprint capacity could be absorbed on an ongoing basis, cutting that iteration cycle roughly in half.

The system also matured in how engineering consumed it. Early on I delivered 60+ component specs to support handoff. As the relationship with developers deepened and we secured dedicated Figma seats for the engineering team, direct component inspection replaced the need for manual specs entirely, a sign the system had become a genuine shared tool, not just a design deliverable.

Beyond the product team, TomTom's central design system team formally adopted our token architecture, and with it, UI patterns and components validated through the mobile product. That adoption confirmed the system was scalable enough to influence TomTom's broader product ecosystem.

Key Takeaway

More than contributing to a design system, I owned a production-grade token pipeline, one that proved flexible enough to support a high-pressure launch, efficient enough to remove engineering bottlenecks, and credible enough to be adopted beyond the team that built it.