SeamlessHR · Dec 2023 – Present
Seamkit
Enterprise Design System Architecture
Designing the operating foundation that allowed a growing enterprise product suite to scale without fragmenting design and engineering decisions.
As SeamlessHR's product suite expanded, locally managed design and engineering libraries turned every change into a coordination problem. Teams needed a shared operating foundation that could scale design decisions consistently across products, platforms, and releases.
As Design Systems Lead, I led the creation of SeamKit—establishing a common operating foundation that enabled product teams to build, evolve, and scale together.
Governance model and contribution SOP
System health instrumentation and adoption tracking
Documentation platform (SeamKit Internal Toolkit)
Figma token sync and engineering integration
- ·Token architecture before components
- ·Lifecycle and contribution governance
- ·Co-created adoption
02 Evidence Behind the Decision
Evidence Behind the Decision
Before any architecture was defined, user testing, library analysis, and stakeholder interviews documented what the legacy ecosystem was costing delivery.
Figure 01 — Collaborative UI audit workshop on FigJam — pan and zoom to explore the session.
- ·The audit revealed 30+ duplicate core components (buttons, inputs) across fragmented libraries.
- ·Sprint metrics exposed an average 14-day feature hand-off — with 7 days allocated solely to UI fixes.
- ·Engineering feedback showed 62% citing style churn as the primary delivery blocker.
- ·Brand review confirmed the new visual identity absent on 70% of live screens.
At the system level, six parallel libraries became one governed stack.
03 Core Tensions
What had to change
Three systemic failures that made a governed baseline unavoidable.
The problem wasn't component shortage — design decisions had no structure that could travel across teams.
Duplicate patterns and local naming conventions turned platform-wide changes into a scheduling problem. Consistency required repeated cross-team effort — not system logic.
A component library with no lifecycle management becomes untrustworthy. Teams fork locally, the shared system fills with exceptions, and the cycle restarts.
Teams will not adopt what they did not help shape. Contribution had to be designed as a path to influence — not enforced from the top.
04 Evidence in Practice
Figure 02 — Three-tier token hierarchy: Core (primitive values) → Decision (Semantic) → Component. 581 primitives · 488 component tokens · 349 colour tokens.
- Token architecture preceded components, trading early visible output for long-term scalability
- Semantic tier separated meaning from raw values, reducing exception-driven drift
- The Decision layer is the theming surface. Brand or compliance changes update one layer and propagate across every component that references it — core values stay stable, components stay untouched.
Figure 03 — Token Studio variables panel: the taxonomy consumed by design and engineering across the platform.
Encoding brand and communication into the system
Figure 04 — Shared component foundations consumed across product teams.
- Component-level overrides were scoped explicitly, preventing semantic tokens from becoming exceptions
- Foundations designed to support multiple product teams without needing bespoke variants per team
Figure 05 — Library analytics validating production reuse.
Figure 06 — Documentation as the operational source of truth.
Figure 07 — Governance workflow: identify need → proposal → community review → draft → stable release. Cadences: Token Council · Component Review Board · Pattern Steering Group.
- Lifecycle stages created a shared definition of stability and deprecation (no silent drift)
- Cadences made governance visible and predictable, increasing trust across teams
Healthy systems aren't measured by migration—they're measured by continued voluntary use.
Figure 08 — Seamkit adoption in comparison to the most active fragmented library (SHR Product v2).
- Adoption was designed as an influence model — audits + working sessions before governance hardening
- Detach rate became a leading indicator of system trust — signalling when teams were routing around the system rather than through it.
Figure 09 — System health survey validating sustained reliance — NPS 57 with no detractors; improvement requests point to scale (variants, alignment), not abandonment.
05 Outcomes
What the system enabled
The operating model had become the default starting point for new product work.
06 Reflection
Design systems become infrastructure when organizations stop thinking about them as libraries and start relying on them as operating foundations. At that point, growth no longer tests whether the system works — it reveals where it needs to evolve.
The system was being stretched because it worked.