Establishing a Design System

A shared language for scale, quality, and speed, contributing to ~15% faster delivery across squads.

Overview

I established HSE’s first Design System to reduce inconsistency and design debt across web and app.

Design system foundations across web and app
Design System V1.

As HSE’s digital ecosystem expanded, teams shipped more features across more surfaces. Over time, UI decisions drifted, patterns diverged, and small inconsistencies turned into design debt.

This showed up in day-to-day work: duplicated components, repeated design decisions, and avoidable QA issues. It also made it harder to keep accessibility and quality consistent across squads.

This case is about how I initiated and helped build the first HSE Design System, a shared language of components and rules that improved speed and consistency across web and app.

Role & Scope

  • Role: Team Lead Product Design (head-of-discipline scope)
  • Scope: Led the initiative from a design leadership perspective, partnered with engineering and product, set standards and contribution rules, and helped teams adopt the system in real delivery work.
  • Channels: Web shop and mobile app (shared UI foundations)
  • Duration: 2021 (with a major review in 2025)

Impact

  • 15% faster delivery across squads
  • Reduced duplication through reusable components and clearer contribution rules
  • Improved consistency across web and app via shared components and accessibility standards

The Problem

As the product grew, UI patterns diverged across squads and platforms. This created inconsistency for customers and friction for teams.

  • Duplicated components and repeated design decisions
  • Inconsistent spacing, typography, and UI behavior
  • Accessibility gaps and uneven quality standards
  • Slower delivery due to rework and unclear ownership

Without shared foundations, teams spent time rebuilding instead of shipping.

The Goal

Create a shared language that helps teams build faster, with consistent quality, across web and app.

  • Establish tokens for spacing, typography, color, and elevation
  • Build a core component library that teams can reuse
  • Set accessibility standards as default, not optional
  • Define contribution rules so the system can evolve safely

How I Led

A design system only works if teams trust it and actually use it. Adoption mattered as much as creation.

  • Started the initiative and aligned stakeholders on the “why”
  • Partnered with engineering on technical constraints and implementation
  • Set standards for tokens, components, and documentation quality
  • Defined contribution rules and a review process to avoid design debt

What We Built

  • Design tokens (spacing, typography, color, layout)
  • Reusable components with documented variants and behaviors
  • Accessibility standards and checklists built into components
  • Contribution rules to reduce duplication and keep consistency
  • Alignment with real product work to ensure adoption

Why It Mattered

The design system became the default way teams built UI across web and app, different surfaces with different tech stacks but shared visual foundations.

Before: components rebuilt from scratch, accessibility gaps uneven, inconsistent spacing and typography across squads. After: shared tokens, documented components with built-in accessibility, and contribution rules that let the system evolve safely.

The bigger win was cultural: the system made quality a team habit, not a heroic individual effort.

Design system foundations across web and app
As HSE’s digital ecosystem expanded, inconsistency and design debt slowed delivery. The design system created shared foundations to scale quality and speed.

Takeaway

A design system only works if teams trust it. Building that trust, across 8 product teams and 3 surfaces (web, iOS, Android), was harder than building the system.