Establishing a Design System

HSE's first design system, initiated during a company-wide rebrand and built from scratch. Adopted across 8 product squads and 3 platforms. ~15% faster delivery. And the harder win: a team that stopped treating quality as someone else's problem.

Overview

I initiated and led the creation of HSE's first design system shortly after joining the company. Working alongside the external agency behind HSE's major rebrand, I contributed hands-on design work (typography, colour, spacing) before building the governance and adoption model that made the system last across web, iOS, and Android.

Design system foundations across web and app
Design System V1.

My direct contribution

Initiation, architecture & adoption strategy

  • Identified and made the case for the system shortly after joining HSE, using the incoming company rebrand as the strategic moment to build proper design foundations
  • Collaborated with the external branding agency that led HSE's rebrand to translate the new visual identity into a systematic, buildable design language
  • Personally designed the token architecture: spacing scale, type scale, colour system, and elevation logic that worked across web and both mobile platforms
  • Wrote the contribution rules and governance model, the part most teams skip and the part that determines whether a system stays alive past year one
  • Ran the accessibility audit that became the baseline for component standards

Team & collaboration

Stakeholder buy-in & org adoption

  • Aligned engineering leads on technical implementation; different stacks on web, iOS, and Android required separate component implementations from shared design tokens
  • Managed adoption squad-by-squad: embedded the system into live delivery work rather than asking teams to stop and "migrate"
  • Set up a review ritual so contributions went through design critique before entering the system
  • Currently leading a major system review (2026), evaluating the system against current best practices: token machine-readability, documentation completeness, and design-to-code alignment

Duration: 2021 (major review ongoing, 2026) · Surfaces: Web, iOS, Android · Squads: 8

Impact

  • ~15% faster delivery across squads after adoption
  • Accessibility standards built into components by default, not added at QA

The Problem

As the product expanded across web, iOS, and Android, and across 8 separate product squads, UI decisions diverged. Each team made reasonable local choices that added up to a global inconsistency problem. Components were rebuilt from scratch because nobody knew what already existed. Accessibility was patched in at QA because it wasn't built into components. Spacing and typography drifted because there were no shared tokens.

The symptom was inconsistency. The cause was the absence of a shared language.

The decision I got wrong first

My initial instinct was to build the system comprehensively before rolling it out. Full token set, complete component library, documented variants, then hand it to teams as a finished product. I was wrong.

When we introduced the first version in 2021, adoption was slower than expected. Squads were mid-sprint. Migrating to new components meant rework they hadn't planned for. The system was correct in isolation but disconnected from how work actually happened.

I changed approach: instead of asking teams to adopt the system, I embedded system work into the squads' own delivery. New features got built with system components from day one. Old components were migrated when the relevant squad had natural rework cycles. Adoption happened through delivery, not alongside it.

This is the lesson I'd give to any design leader starting a design system: the governance and adoption model matters as much as the component library.

What we built

  • Design tokens: spacing scale, type scale, colour system, elevation, shared across web and mobile
  • Reusable components with documented variants, states, and behaviours
  • Accessibility standards built into components, not a post-hoc checklist
  • Contribution rules and a review process so the system evolves without accumulating new debt

Takeaway

A design system only works if teams trust it. Building that trust, across 8 squads and 3 platforms, was harder than building the system. The adoption model is the product.