Case study · VitalHub UK · Design systems

A design system for MyPathway, built from a blank page.

I created MyPathway’s first design system: colour, type, spacing, icons, 46 documented components and the rules that tie them together. It grew through three versions of the app, and five developers built the whole redesign from it.

Home built from the system
Question screen built from the system

01 · Overview

One shared language for a product many services configure.

Product

The MyPathway patient app, used across NHS services

Problem

The old app had styles but no system, so every feature added new one-off UI

Role

UX / UI Designer. I created and owned the design system

Team and time

2 designers (I led), 5 developers, 1 PM · built across 6 months

Scope

Audit, foundations, components, patterns, accessibility, documentation, handoff, design QA

Outcome

Every screen in the release built from one shared library

30

colour steps across three brand scales

46

components in seven groups, each documented in five layers

13.4:1

contrast on the primary button (AA needs 4.5:1)

02 · The challenge

The old app had styles. It didn’t have a system.

Old timeline with heavy coloured frames
Colour meant typeNot what to do
Old web-style sign-in buttons
No button rulesOne-off blue and grey

My audit of the old interface found four problems:

  • Colour meant content type, so it couldn’t also mean “needs you” or “done”.
  • Heavy frames and a grid background made every card shout equally.
  • No button rules. Sign-in used a blue and grey that appeared nowhere else.
  • Status written four ways: “Overdue”, “To Do”, “Booked” and “!” icons.

Why it mattered now: five developers were about to build a full redesign in parallel, for services that each configure their own content. Without one source of truth, we would have shipped five slightly different apps.

03 · Design decisions

Colour means status. Everything else stays calm.

I built three 10-step scales from the logo, then gave each colour one job. Screens use roles such as status.attention, not raw hex values.

Dark blue
Pink
Green
Dark blue

Text, actions and navigation

Pink

Needs you: due, upcoming, in progress

Green

Done, selected, safe

Decisions that came from the versions

Version 1 question with pink Next
Final question with dark Next

Pink stopped being a button

V1 used pink for Next, and pink also meant “due”. Actions and warnings looked the same.

Rule: pink is status, never an action. Every primary action is Dark Blue 90.

Version 2 Home with coloured tiles
Final Home with white cards

Colour moved into badges

V2’s full-colour tiles looked bold, but competed with status chips.

Rule: colour lives in small badges and chips. Surfaces stay white.

Version 1 photo resource cards
Final compact resource cards

Content before photos

V1 photo cards fitted about two resources per screen.

Rule: imagery only where it explains something.

04 · Testing and iteration

Every version reviewed the UI, not just the UX.

The system wasn’t designed once and handed over. Each version of the app was reviewed with internal staff completing real patient tasks, and what confused people became a rule. We hadn’t yet tested with recruited patients, so we treated these as early findings.

The active tab rose out of the bar, so the shape jumped with every tap

→

A fixed tab bar with Pathway as the raised centre

Many screens shared a logo header and looked the same

→

Every header names its page, with the back arrow on the left

Dialogs appeared for actions that couldn’t be lost

→

Dialogs only before loss, and they say what happens next

Green 100 text failed contrast at 2.0:1

→

Green is for fills and icons only; text on green uses Dark Blue 100

6 of 7

testers completed the questionnaire task, built from the system, without any help

17.5:1

body text on white

10

status chips, each with a word, so colour never works alone

05 · Delivery

46 components in seven groups, each documented the same five ways.

The team built from one shared library. Every component is written up in five layers.

01

Definition

Purpose, variants, interaction states and anatomy

02

Design tokens

Type, spacing, semantic colours, borders and focus

03

Accessibility

Contrast, keyboard behaviour, labels, screen readers

04

Implementation

Design-to-code handoff and documented QA changes

05

Reuse

Where it appears across screens and workflows

Appointment card in four variants
Appointment card, four variants
Collaboration and handoff
  • Clear naming: scales by step (Blue 90), roles by purpose, components by job
  • Every state drawn: default, pressed, selected, disabled, error, empty
  • Tokens by name for developers, not screenshots
  • A contribution path: need → check library → propose → review → release
  • Design QA: changes logged against the component, so fixes went into the library

06 · Impact and reflection

One language, and an honest view of what’s next.

Verified evidence
  • Every screen in the final release built from the library
  • 30 colour roles plus radius, elevation, spacing and focus tokens, all taken from the final screens
  • Every text and colour pair checked against WCAG 2.1 AA
  • Five developers built in parallel from one source
Product context

MyPathway runs across NHS services and has reached more than 1.8 million patients. The system means the next service gets a calm, consistent app from day one.

Limitations

We didn’t measure adoption or build time as numbers. Accessibility is calculated and specified, but not yet audited with assistive-technology users, and four colour pairs still fall short of AA, each with a fix ready.

Future measurement
  • Share of screens built only from library components
  • Design QA issues per release
  • An accessibility audit with screen-reader users
  • The four contrast fixes, and tokens synced into code

A design system is a promise that the app behaves the same way every time a patient opens it.

The full case study is password protected. Ask me for the password and I’ll send it over.