Design System

Alivecor / 2025

Design
System

A custom design system for a cardiac health app — built from scratch to unify a product that had outgrown itself.

Role: Lead Designer
Timeline: 4 Weeks
Delivered: Foundations & Components

Design

Context

Kardia by AliveCor is a consumer cardiac health app — patients record ECGs, share results with a cardiologist, and track heart rhythm over time. The interface has to feel calm for an anxious patient, while staying precise enough for a clinical read.

Years of organic growth. no shared component library, so every sprint added its own headers, buttons, and fonts.
Not a rebrand. the Kardia DS is infrastructure — a shared language the product could scale on without repeating old debt.

A design system for a cardiac health app has to earn trust twice: once with the patient who needs to feel calm, and again with the clinician who needs the data to be unambiguous.

Team

AdityaLead Designer

Sprint PartnerDesign Contractor

KatieProduct

AnujEngineering Lead

AlyssaMarketing

Scope

Foundations — color, type, spacing, elevation
Cross-platform token architecture
Core component library in Figma
Handoff-ready for iOS, Android, Web

The Problem

The Kardia Consumer App grew screen by screen, with no shared component library. It worked — patients used it, cardiologists relied on it — but the debt was real and it was accumulating.

No single source of truth. 15+ workflows lived in disconnected Figma files, with no way to propagate a change across screens.
iOS-only fonts in cross-platform designs. SF Pro Display and SF Compact Text are Apple system fonts — Android and Web had no equivalent.
No token handoff. every platform reimplemented color, spacing, and radius independently. Values drifted across iOS, Android, and Web.

An audit that catalogued every workflow into one file made the inconsistency impossible to ignore — six typefaces in active use across 15 workflows, none of them cross-platform, and six header patterns, none sharing a component or token.

SF Pro Display Bold — account deletion, onboarding headers (iOS only)
SF Compact Text Regular — body copy, confirmation dialogs (renders differently per OS)
SF Pro Rounded Medium — KardiaMobile setup screens (inconsistent with the rest of the product)
SF Compact Text Medium — input fields, form labels (mixed with SF Pro Display on the same screen)
Helvetica Neue — older onboarding flows, legacy fallback
System UI — web product pages, undeclared, browser decides

Tutorial Popup

The onboarding tutorial popup showed the same debt from a different angle — eight variants of the same component turned up side by side in the file, each one solving step navigation on its own.

Half use a chevron-and-slider pattern with a live step counter; the other half collapse it to a single button still labeled TEXT — a placeholder that was never filled in. Whether the close affordance or the illustration block shows up depends on which copy of the component someone happened to duplicate.

Variants found in the file: 8
Navigation patterns: 2 — chevron+slider vs single button
Button label reading literal "TEXT": 4 of 8
Close (X) affordance: present on 4 of 8, missing on the rest

The System

Off-the-shelf kits don't fit cardiac health — color semantics can't conflict with accessibility rules for error and warning states, and the tone has to read as both calm and precise.

Foundations first. color, type, spacing, radius, and elevation, locked before a single component was touched.
Components second. starting with buttons — the highest-frequency element, and the one that stress-tests every semantic variant at once.

Foundations first. You cannot build stable components on top of an unstable token system.

What shipped

Design Tokenscolor, spacing, radius, type, shadow

Component Librarybuttons, inputs, modals, cards, nav

Foundationstype ramp, spacing scale, elevation, grid

Cross-platform handoffone JSON source → SwiftUI, Compose, CSS

Sprint timeline

Week 1Color, typography

Week 2Spacing, radius, elevation

Week 3Buttons, inputs, forms

Week 4Navigation, modals, docs

Color Foundations

The old system used loosely defined semantic tokens named after moods — Mindful Blue — with no primitive scale underneath. The new system starts from a structured 0–900 primitive ramp with AA contrast ratios at every stop, before any semantic meaning is assigned.

Primitive first. brand and premium each get a full 0–900 ramp — every step carries a documented AA contrast score, not just a color guess.
Two identities, not one. brand (blue) carries the core product; premium (purple) is reserved for KardiaCare, the membership upsell, so the two never compete for attention.

Before / after — the color system

Before — old DS

Semantic tokens named after colors. No primitive scale. No contrast ratios documented.

After — Kardia DS

0–900 primitive scale. AA contrast ratios at every stop. Semantic tokens reference primitives.

Before — premium theme

Flat semantic tokens. Premium Purple #885FA5 with opacity variants. No scale.

After — premium palette

Full 0–900 primitive scale. Premium features draw from the same token architecture as brand.

Primitive → semantic → component

PrimitiveSource of truth

brand/600

#113A69

Raw value. Never used directly in components.

SemanticIntent layer

color.primary.bg

→ brand/600

Assigns meaning to a primitive. Component-agnostic.

ComponentUsage layer

button.primary.bg

→ color.primary.bg

Wires semantic to a specific component context.

Brand — primitive scale

#f8fbfe

#f2f7fd

#b9d4f3

#478fe1

#206dc5

#174e8c

#113a69

#0c2746

#061323

#030a12

Premium — primitive scale

#f8f4fa

#ebe4f3

#d9c7e6

#c2a0d9

#a77bca

#885fa5

#6b4983

#573d6a

#3e2550

#1b1023

Typography

Designers reached for Apple system fonts because Figma bundles them and they preview well on a Mac — but SF Pro doesn't exist on Android or Web. Engineers improvised, and the product looked different on every platform.

DM Sans. a variable font on every platform via Google Fonts, geometric-humanist, legible from label to display size.
Plus Jakarta Sans. the structural companion — narrower, higher x-height — for metadata and UI chrome.

Type ramp — DM Sans, cross-platform

Display · 40 / 700

Track your heart health, every day.

H1 · 28 / 700

Recent Recordings

H2 · 22 / 600

Account Settings

H3 · 18 / 600

Notification Preferences

Body · 16 / 400

Your ECG results will be reviewed by a certified cardiologist within 24 hours.

Label · 13 / 500

NORMAL SINUS RHYTHM

Caption · 12 / 400

Recorded 14 Jul 2025 · 9:41 AM

Buttons

Buttons came first because they carry the highest semantic weight in the product. The system defines four roles — Brand, Destructive, Success, Neutral — each with three hierarchy levels and five documented states.

Brand is blue, not a mood. the primary role resolves to the brand primitive scale — a systematic 0–900 ramp, not a hand-picked hex like the old Pill_CTA_Green or Ghost_Link_Blue.
Naming carries the role. Action_Button/OLDandCrusty became Button / Destructive / Primary — the semantic role is explicit in the name, not the hex.

After — Kardia DS, full specification

Every role across solid, tinted, outline, and disabled states.

Before — Action_Button, pre-DS

Hand-recolored per screen, no semantic naming behind the fills.

Use Destructive Primary for anything that permanently removes data
Stack buttons vertically with Primary on top in mobile contexts
Match a button's role to the action, not the visual weight you want
Use Ghost buttons for inline contextual actions within content
Pair a Primary with at most one Secondary or Ghost counterpart

Don't

Hardcode a fill color — always reference a semantic token
Use Brand Primary for a destructive action because it looks bolder
Place two Primary buttons side-by-side at the same hierarchy level
Re-skin a button with a custom fill outside the token system
Use more than two action buttons in a single bottom action area

Tokens in Code

Before the DS, the same color was defined three times — a Figma fill, a Swift constant, an Android XML value — and they drifted apart with no shared reference.

Tokens live once, as JSON. a build step resolves them to SwiftUI, Compose, and CSS, so what designers see is what engineers ship.
Named at the semantic level. not the primitive — so component code stays stable when the underlying value changes.

TokenValueUsage

color.brand.600#113A69Primary CTA background

color.error.600#cc3d3fDestructive action, error state

color.neutral.900#182c3dBody text, headings

color.neutral.300#c6ccd2Borders, dividers

color.premium.600#6B4983Premium feature surfaces

radius.sm4pxButton, input, small card

radius.md8pxModal, sheet, overlay

shadow.elevation.10 1px 4px rgba(0,0,0,.10)Card lift, floating element

font.heading1DM Sans / 700 / 28pxPage title, screen header

font.bodyDM Sans / 400 / 16pxBody copy, descriptions

SwiftUI · iOS

extension Color {
  static let brandPrimary =
    Color(hex: "#113A69")
  // color.brand.600

  static let destructive =
    Color(hex: "#cc3d3f")
  // color.error.600

  static let premium =
    Color(hex: "#6B4983")
  // color.premium.600
}

Android · Compose

val KardiaColors =
  lightColorScheme(
    primary =
      Color(0xFF113A69),
    // color.brand.600

    error =
      Color(0xFFCC3D3F),
    // color.error.600

    tertiary =
      Color(0xFF6B4983),
    // color.premium.600
  )

React · CSS Tokens

:root {
  --color-brand-600: #113a69;
  --color-error-600: #cc3d3f;
  --color-neutral-900: #182c3d;
  --color-premium-600: #6b4983;
  --radius-sm: 4px;
  --font-body: 'DM Sans', sans-serif;
}

Process

The sprint rule was strict: no component work until color, type, and spacing were locked. Starting components before the token system is stable means either building twice or shipping components that reference values that change underneath them.

Engineering was involved early. Anuj reviewed the token naming in Week 1 and caught a naming conflict with an existing Android convention — that conversation saved days of re-work in Phase 3.
Week 1 was audit and decisions only. no Figma components built. That discipline paid off in Weeks 3 and 4 — not a single component revision was triggered by a foundation-level change.

Phase 3 is ongoing. The system is built; adoption — engineering token implementation, app redesign rollout, contribution model — is where the ROI materializes.

1Complete

Foundation

Weeks 1–2

All Screens audit
Brand color alignment
Primitive token scale, 0–900
Semantic token mapping
DM Sans type ramp
Spacing · radius · elevation
Engineering token review

2Complete

Components

Weeks 3–4

Button system — 4 roles × 3 levels × 5 states
Text input and form fields
Modal and alert sheet
Bottom navigation
Card and surface
Usage guidelines
Engineering handoff spec

3In Progress

Adoption

Ongoing

iOS token implementation
Android token implementation
Web CSS token implementation
Kardia app redesign rollout
Contribution model
Version and changelog

Impact

What the system enables, by function.

Product

Shared components ship in hours, not days
Brand consistency without per-screen review
Foundation for product expansion without new debt

Design

One library, one source of truth — no drift between files
Update a token, not 40 component instances
More time on interaction design, less on visual QA

Engineering

Accelerated development across iOS and Android
Token handoff eliminates interpretation drift between platforms
Shared naming convention reduces designer–engineer friction

Learnings

What this sprint taught me about building a design system inside an org.

Bring more stakeholders in from the beginning so everyone is on the same page before any decisions are made.

Marketing has to be involved from the start — brand color and voice decisions made without them create re-work later.

Engineering brings essential context for decision-making. Token naming, platform constraints, and feasibility calls are better made together, not handed over.

Have clear, agreed-upon goals from Business, Product, and Engineering before the system work begins. A design system without a shared north star serves no one.

Chase the north star. The system is infrastructure, not a deliverable. Keep the long-term product goal visible so every foundation and component decision points toward it.

Next Exploration

Design
System

Context

The Problem

Tutorial Popup

The System

Color Foundations

Typography

Buttons

Tokens in Code

Process

Foundation

Components

Adoption

Impact

Product

Design

Engineering

Learnings

Year In Review

Design
System

Context

The Problem

Tutorial Popup

The System

Color Foundations

Typography

Buttons

Tokens in Code

Process

Foundation

Components

Adoption

Impact

Product

Design

Engineering

Learnings

Year In Review

DesignSystem

Context

The Problem

Tutorial Popup

The System

Color Foundations

Typography

Buttons

Tokens in Code

Process

Foundation

Components

Adoption

Impact

Product

Design

Engineering

Learnings

Year In Review

DesignSystem

Context

The Problem

Tutorial Popup

The System

Color Foundations

Typography

Buttons

Tokens in Code

Process

Foundation

Components

Adoption

Impact

Product

Design

Engineering

Learnings

Year In Review

Design
System

Design
System