01 — Context
Two products, years of drift, no shared language
Book4Time is an enterprise SaaS platform powering spa, wellness, and hospitality operations across 100+ luxury resort properties. By the time I joined, the product had accumulated years of inconsistency across two separate products that had grown apart independently — duplicated components, divergent color values, no shared language between design and engineering.
There was no design system. There was no single source of truth. Every sprint meant rediscovering what already existed — or building it again from scratch. And the scope wasn't one codebase of drift: it was two.
"The hardest decision wasn't which components to build first — it was what 'unification' meant across two products that had grown apart for years. I had to answer that before I designed anything."
02 — Problem
Inconsistency at scale creates compounding costs
A component audit across both products revealed dozens of button variants with no documented rationale. Color values were hardcoded. Spacing was arbitrary. The same component had been rebuilt differently in each product — sometimes with different names, sometimes with different behaviour. Developers were building to inconsistent specs, and QA was catching design bugs that should never have shipped.
The hardest part of the audit wasn't finding inconsistencies — it was deciding what unification meant across two products with different histories. Full unification up front would slow adoption on both teams. But supporting parallel patterns defeated the purpose. That decision had to be made before a single component was designed.
Component fragmentation
Dozens of button variants, inconsistent form patterns, and one-off components with no documentation or usage guidance.
No token architecture
Color, spacing, and typography values were hardcoded — impossible to theme or update at scale without touching every component.
Design–dev disconnect
No handoff standards, no shared component library. Every sprint meant re-translating design intent from scratch.
No governance
No process for how components got created, reviewed, or deprecated. The system, such as it was, lived only as tribal knowledge.
03 — Approach
Token-first, then components, then governance
I structured the build in three deliberate phases. Starting with tokens was a conscious choice — without a shared semantic layer, any component library becomes a maintenance burden almost immediately.
Design tokens
Established a three-tier architecture: primitive values (raw colors, sizes) → semantic aliases (color.action, color.surface) → component-level tokens. This gave every value a traceable source and made theming possible without touching component code.
Component library
Built on the token layer, prioritising highest-reuse components first: buttons, forms, cards, modals, navigation. Each component shipped with usage guidelines, anatomy breakdowns, do/don't patterns, and accessibility annotations.
Governance model
A contribution process, review workflow with engineering, deprecation checklist, and monthly design system office hours. The goal was making the system maintainable by the team — not just by me.
04 — Signature component
The service card: progressive disclosure at the core of the booking flow
The most complex and high-impact component was the service card — the primary interface for browsing, selecting, and configuring spa treatments. It needed to handle multi-select add-ons, technician preferences, time slot selection, and multi-date cart grouping in a single, coherent component.
The design challenge was layering this complexity without overwhelming guests. The solution was progressive disclosure: a collapsed default state showing only the essential — service name, duration, price — with an expanded state unlocking the full configuration without navigation away from the browsing context.
05 — Governance
A system without governance is just documentation no one reads
The hardest part of a 0-to-1 design system isn't building the components — it's keeping the system alive after launch. I designed a contribution model that made it easy for product designers to propose and contribute without fragmenting the library.
That urgency was earned the hard way. Three months into the build, I discovered that engineering had been implementing hardcoded color values in a parallel sprint — before the semantic token layer was finalised. Walking it back required more trust-building than design decisions, and it made one thing clear: governance couldn't wait for the library to ship. A contribution process needed to exist before teams started contributing without one.
The model included: a component request template with a clear acceptance criteria checklist, a joint design-engineering review process, a deprecation workflow, and monthly office hours for design system questions. Component adoption was tracked across feature teams so we could see where the system was working and where it wasn't.
"Anyone can build a component library. Making it a living system that a team can maintain without you — that's the hard work."
06 — Outcomes
The first feature built on the system went through handoff without a reconciliation sync
The system went from nothing to a production-ready library used across product squads — with zero-configuration theming ready for future white-label opportunities across the 100+ enterprise properties on the platform.
- First design system shipped for the platform — tokens, components, and documentation in production
- First feature built on the system went through handoff without a single reconciliation sync — the concrete signal that the shared language was working
- New feature design time reduced: teams assembled screens from existing components rather than starting from scratch each sprint
- Design-to-dev handoff friction eliminated — shared component specs and interaction states replaced per-sprint renegotiation
- Contribution model adopted by the full design team, enabling system growth without routing every request through one designer
- Token architecture ready for zero-configuration theming across future white-label enterprise properties on the platform
07 — Reflection
What I'd do differently
If I were starting this system again, I'd invest earlier in engineering partnership. Having an engineer embedded in the design system work from week one — rather than month three — would have aligned the token architecture with theming implementation from the start, saving a round of rework.
I'd also build the governance model earlier. I shipped it after the initial component library, which meant a few months of ad-hoc contributions that needed retroactive cleanup. The contribution model should launch alongside the first components, not after.