80% of the team's time went into rebuilding the same UI three times. DS 3.0 flips that.
ChargeHub had quietly drifted into three different products on web, iOS and Android. Rebuilding it on semantic tokens meant design stopped being a static image and became a set of values all three platforms could read.
ChargeHub's web and mobile apps had drifted apart, and 80% of the team's capacity was going into rebuilding the same UI three times. Rewiring the system onto semantic tokens turned that ratio around without touching a line of component logic.
- Role
- Principal Product Designer
- Product
- ChargeHub: EV charging map, web and mobile
- Scope
- System architecture, tokens, migration plan
- Platforms
- Web, iOS, Android
- Design systems
- Design tokens
- Figma variables
- Accessibility
The hidden cost of fragmentation
ChargeHub powers EV charging across web, iOS, and Android. Over time, independent releases caused the three platforms to quietly diverge into completely different user experiences.
This drift never appeared as a single massive expense, making it hard to track. Instead, the cost was systemic: teams lost alignment across platforms, users experienced fragmented features depending on their device, and developers absorbed the difference through constant rework.
Four ways platform drift drained velocity
Individually, each issue felt minor. Combined, they consumed most of the team's engineering capacity.
Platform fragmentation
Features looked and behaved differently across web, iOS, and Android, creating siloed user experiences and fragmented platform logic.
Manual translation
Developers had to interpret static mockups by hand, leading to hex-hunting, magic numbers, and high error rates during implementation.
QA bottlenecks
Design reviews repeatedly devolved into pixel-pushing because there was no single source of truth to guarantee compliance at the root.
The velocity tax
Shipping any new feature required rebuilding the exact same UI components three separate times from scratch.
Without a centralized token layer, even a single primary CTA ended up with three distinct spec sheets. Basic properties like corner radius, padding, and brand hex codes were hardcoded independently per platform, accumulating subtle design debt over time.
Flipping the capacity ratio
Before DS 3.0, roughly 80% of design and engineering capacity was consumed by execution overhead: handoff guesswork, manual platform recreation, and surface-level QA debugging. Only 20% actually went toward advancing the core product roadmap.
Variables store values. Semantic tokens capture intent.
A primitive is a raw constant (e.g., #18D1AE or 16px). It defines visual styling but carries zero context. A semantic token wraps that value in role-based logic: instead of hardcoding green, it assigns functional meaning like bg-brand-primary or action-default.
This abstraction layer decouples design decisions from platform code. Updating a single global token updates every referencing component across Web, iOS, and Android simultaneously without touching component-level code.
Interactive demo: One token schema, three platforms
An interactive demo runs the same charging screen through three states on web, iOS and Android. First, three platforms holding three sets of hardcoded values: corner radius of 4px, 26px and 2px, horizontal padding of 16px, 28px and 12px, and three near-identical but different brand hexes. Second, the same three screens reading real DS 3.0 tokens instead: Component/Button/radius, Component/Button/md/padding-x, Component/Button/md/padding-y and Button/primary/bg. The values become identical because they are literally the same value. Third, a live version where switching colour mode or type-and-spacing mode updates all three platforms at once.
Mode-driven responsiveness
An interactive diagram shows the responsive behaviour of DS 3.0, where type and layout are driven by one shared mode rather than by media queries. In Desktop mode, Typography/display-2xl resolves to the display-2xl primitive at 72px on a 90px line, and Layout/container-padding resolves to spacing-8 at 32 pixels. Switching to Mobile mode, the same type token resolves to display-xl instead at 60px on a 72px line, and the same layout token resolves to spacing-4 at 16 pixels. Every display step drops exactly one rung and section-padding-y drops from 64 to 40 pixels, while no token name changes anywhere. Three things hold on purpose: Typography/text-md stays at 16px because body copy should not shrink on a phone, and Layout/gutter and Layout/max-width stay at 32 and 1280 pixels. Both systems resolve through the same 8-point spacing ramp, running from spacing-1 at 4 pixels to spacing-32 at 128 pixels.
System capabilities in action
Because every UI element is bound to semantic tokens, switching modes transforms entire screen layouts instantly. System-level capabilities like dark mode, compact mobile density, and localized layout shifts execute centrally without manual component editing.
The sandbox: speed to signal
User research needs to move faster than production release cycles. DS 3.0 introduces a dedicated sandbox so designers can assemble high-fidelity prototypes in minutes using production foundation tokens, focusing effort entirely on testing new concepts.
Designers start with system components and are given explicit permission to modify or detach elements within the sandbox. Production libraries remain strictly tokenized and WCAG-compliant, while the sandbox serves as an unconstrained proving ground for usability testing.
This isolation protects core library hygiene. Previously, building prototypes directly within shared files polluted primary components with one-off experiment states. Separating research exploration from production infrastructure provides speed for testing while maintaining strict system governance.
Sandbox output in practice
The innovation loop
A five-step loop takes a detached experiment back into the system. One, rapid experimentation: break the link and move at the speed of thought, without polluting the core library. Two, high-fidelity validation: user-testing prototypes in minutes with zero developer effort, iterating until validated. Three, the system handshake: collaborative review of logic, edge cases and accessibility before anything becomes official. Four, semantic mapping: translate the validated design into reusable tokens and constants, so detached pixels become standardised tokens. Five, unified implementation: ship it into production across web, iOS and Android against a single source of truth.
Architectural trade-offs: Speed vs. governance
Allowing un-tokenized exploration introduces risk: user-tested prototypes can build momentum before accessibility or system compliance is verified.
Instead of restricting design velocity, I contained the blast radius. The sandbox remains a strictly isolated copy, preventing accidental production leakage, while the handshake serves as an enforced gate prior to tokenization. Slowing down research to match production speed creates far more organizational drag than managing sandboxed risk.
The system dividend
The core thesis of DS 3.0 was never about visual polish alone, but operational velocity. By automating cross-platform execution mechanics, design and engineering teams redirect focus toward product strategy and roadmap delivery.
Note: The metrics below reflect the strategic ROI projections used to secure business case approval prior to rollout.
- 80/20 → 20/80 — The effort split, inverted
- ~50% — Faster handoff: a recipe, not a picture
- ~40% — Fewer UI bugs: one source of truth
- ~5× — Experimentation velocity
System maturity & rollout
The underlying architecture is validated and production-ready. With the sandbox fully operational, product teams can design, prototype, and research in an isolated environment, promoting only validated patterns into core system tokens.
System migration is deliberately non-disruptive. Upgrading the foundation while preserving feature uptime, semantic tokens replace hardcoded constants at the build level without altering component structures. Legacy screens are refactored incrementally as they come up on product roadmaps.
For end users, this architecture unlocks seamless cross-platform consistency across iOS, Android, and Web. The core technical foundation is complete; focus now shifts entirely to phased product adoption.
Proven
Token architecture verified across Web, iOS, and Android. Sandbox validation loop and component intake paths fully established.
In progress
Organization-wide adoption. Progressively migrating feature teams and legacy views onto the new foundation without interrupting sprint velocity.
Still to measure
Long-term production telemetry. Engineering efficiency and velocity metrics will be benchmarked once migration reaches critical coverage.
As sole architect, I defined and deployed DS 3.0 from scratch: token structure, light/dark themes, the sandbox, migration plan, and the business case that secured leadership buy-in.
The architecture addresses two systemic problems: developer handoffs required interpretation instead of execution, and rapid design experimentation continuously introduced technical debt into core production libraries.