Pronto

Building a Governed, Token-Based System for Product and Engineering

UI Audit & AnalysisStrategic PlanningStakeholder AlignmentQuality AssuranceCross-Functional CollaborationDocumentation & Governance
My role
Lead Product Designer, sole design authority
Team
1 Product Manager1 Project Manager1 Business Analyst3 Front-End Engineers1 Back-End Engineer
Timeframe
6 months

Image placeholder

Pronto product interface showing the refreshed component set after the design system rollout

Drop a 2x PNG export here

Design-to-handoff time dropped 40%, QA-raised inconsistencies dropped 60%, and the end-to-end design process ran 50% faster. The button component alone went from 11 divergent variants down to 5 that covered every required state.

40%

Design-to-handoff time

60%

QA-raised inconsistencies

50%

End-to-end design process

30%

Engineering effort per release

The problem

Pronto had accumulated significant UI debt across years of incremental development, with no shared foundation between design and engineering. This slowed delivery, created inconsistencies in production, and made scaling the product across teams and regions increasingly difficult.

UI issues were surfacing as bug-fix requests and support tickets, with a recurring theme of "visual mismatches" and "technical misalignment." Stakeholders were calling for a full interface upgrade, and the business drivers shaping the project were a fixed 6-month timeframe, one engineering squad already working concurrently on other critical features, and a set of stakeholders with their own timelines: Havas Health, a large New York-based customer, wanted visible layout and feedback improvements; the CEO had committed to a full-scale redesign with added features; and a rename and rebrand of the platform was happening at the same time, run by an external agency.

Discovery

An audit catalogued every duplicated pattern, colour value, spacing unit, and component variant across the platform. It surfaced 213 discrepancies.

Image placeholder

UI audit spreadsheet cataloguing colour, spacing, and component discrepancies

Drop a 2x PNG export here

Usability testing and peer research with designers and engineers surfaced how those inconsistencies were being felt day to day: which components people avoided, where they built workarounds instead of raising a ticket, and which parts of the platform felt most fragile to touch. That shaped how I approached prioritisation once the scope was clear.

The PM, BA, and FE lead were engaged early to discuss the right approach without burdening the roadmap or disrupting workflows users relied on daily.

The decision

A full 0-to-1 rebuild of the system would have taken the project past the 6-month deadline. The PM understood the case for it but pushed back on investing significant time in a system-wide clean-up on top of everything else in flight.

Decision

Middle path over full rebuild

The alternative on the table was a ground-up rebuild of every component before touching production UI. It was ruled out because it didn't fit the timeframe or the engineering capacity available, and it would have delayed the priority-page improvements Havas Health and the CEO were expecting first.

Instead, priority pages were upgraded first, with more complex workflows deferred to a later phase with a firm date. UI cleanup ran in three steps: consolidate documented design decisions to reduce code bloat, constrain every change to only the necessary code with no logic rewrites, then codify the result as a governed system in Figma and Storybook.

The button component is the checkable number for this decision: 11 divergent variants across the platform, consolidated down to 5 that covered every required state.

Image placeholder

Button component before cleanup and rebrand, 11 variants

Drop a 2x PNG export here

Before cleanup and rebrand

Image placeholder

Button component after cleanup and rebrand, 5 variants

Drop a 2x PNG export here

After cleanup and rebrand

Token architecture, built with engineering

The token architecture was designed to close the gap between design intent and production output. Primitive and semantic layers were established separately, with the token structure, naming conventions, and governance model defined in collaboration with engineering rather than handed to them as a finished spec. Every UI decision became traceable, consistent, and easier to implement across teams and regions.

Image placeholder

Variables categorised into primitives and semantics

Drop a 2x PNG export here

Image placeholder

Primitive values applied to semantic variables

Drop a 2x PNG export here

Image placeholder

Semantic tokens used to define design decisions

Drop a 2x PNG export here

Components were built and published in a dedicated Figma library, letting product and design ideate and concept faster. Standardised UI patterns brought consistency across the product, reduced inconsistencies in production builds, and created a clearer handoff process without ambiguity, which is what let the system scale across all new features.

Image placeholder

Components built with all existing variants

Drop a 2x PNG export here

Image placeholder

Components published to the design library

Drop a 2x PNG export here

Image placeholder

Component variant controls in the right-side panel

Drop a 2x PNG export here

Adoption

Training sessions aligned product and engineering on the new standards. Documentation and working examples let PMs and engineers self-serve and cross-check without needing designer sign-off on every change.

Image placeholder

Storybook implementation of the token-based component library

Drop a 2x PNG export here

This work was scoped for responsive web across desktop and mobile browsers. Native iOS/Android component design wasn't part of it directly, though the underlying discipline, token architecture, semantic layering, and cross-platform governance, is the same skill set that native work would build on.

Outcome

The system moved from a source of inconsistency to a source of shared truth that engineers and product could work from without designer guidance. QA-raised discrepancies measurably dropped within the first two sprints post-adoption, and new features no longer needed design-debt remediation before shipping.

Token-based handoff replaced annotation-heavy specs, cutting the back-and-forth between design and development at every delivery cycle. The cleaned-up system became the baseline for every subsequent product surface, and the single most leveraged piece of work across the platform upgrade. Stakeholders were satisfied with the outcome: the refreshed priority modules shipped on time, preserving relationships that a missed deadline or disrupted rollout would have strained.

Learnings

  • Cataloguing every inconsistency before building anything took longer upfront than jumping straight to solutions, but it meant governance decisions were based on the full scope of the problem, not the first few duplicates noticed.
  • The system stuck because engineering helped define the token structure, not because they were handed one to implement. Involving them at the architecture stage was what made adoption real.

What's next

Extending token coverage to native mobile components, and building automated visual-regression checks against the token library so drift gets caught before it reaches QA.