TIMELY
Turning a design system into a delivery standard
When I joined Timely, the design system was developer-led, largely invisible to designers. The product had accumulated more than 300 unique colour values with no semantic meaning, components disconnected from any shared foundation, and multiple generations of branding coexisting in the same product. The real challenge turned out to be not the system itself, but the conditions that kept making inconsistency easy to ship.
The decision to rebuild
The audit made patching an unrealistic option. The architecture was too shallow and the system had no real adoption to protect. I brought the findings to the engineering team and together we decided to rebuild from scratch, on a proper token foundation that would work consistently across the product's mixed technical stack.
Primitive, semantic and component token structure
Multi-brand and multi-platform support across desktop and mobile
Synced directly to Azure DevOps via Tokens Studio
WCAG compliance checked at component level
Connected workflow across Storybook, Chromatic and Supernova
Extended beyond UI to cover error handling, input validation standards and product communication rules
From education to enforcement
My first approach was education. Design reviews, guidelines, sessions with designers. It improved design quality but did not change what reached production. Under deadline pressure, engineers copied familiar legacy code because it was faster.
The fix was structural. We introduced an automated pull request check that scanned for hardcoded values and legacy component usage. New features had to be built with new components and tokens. Feature updates had to reduce legacy component usage by at least 30%. Bug fixes were excluded.
That single change moved adoption from something people were encouraged to do into something the delivery workflow required.
Making it visible and official
Automated Slack reporting tracked token coverage, new components added and legacy components removed in the codebase, giving the whole team a live picture of progress. A public kanban let designers and engineers see what was available and what was coming next, so they could plan around it rather than discovering gaps at handoff.
I made the case for design system adoption as a delivery standard to reduce technical and design debt and improve accessibility across the product. As a result, reducing legacy components across core user journeys was introduced as an OKR for selected product teams. It gave teams the mandate to plan their roadmap specifically around migration, not just address it during feature delivery.
Proof at scale
To support adoption in practice, I joined one product team to redesign the calendar from scratch. The calendar was the right choice: it touches scheduling, billing, client management and multiple teams across the business. If the system could hold there, it could hold anywhere.
This was a full end-to-end design process, starting with quantitative data, journey mapping, broken journey identification and accessibility checks, through to testing, validation and iteration. Using system components and tokens throughout was a core requirement of the project, but it was not the whole story.
Outcomes
High adoption across core parts of the product, tracked through component and token usage
More than 90% of hardcoded values replaced with tokens
More than 40 tokenised and documented components in the library
Engineers reported lower duplication and reduced maintenance effort
What I learned
Adoption does not happen because a system is well designed. It happens when it becomes part of how work gets done. The most effective thing I did was not education or documentation. It was embedding the system into delivery workflows and making progress measurable. Once adoption had a mechanism behind it, everything else followed.
