American Family Insurance · Design Systems

Managing today’s systems while building tomorrow’s foundation

I directly governed 100+ production tokens across My Account and Homesite while separately helping build EDS through token refactoring, reusable components, accessibility standards, and contribution rules.

Explore the case study

▦100+production tokens governed

↻23/27planned EDS tokens

✚28/45EDS components

Role: Senior Product Designer
Scope: Foundations + Components + Governance
Tenure: Mar–Dec 2025

Portfolio reconstruction; proprietary implementation details omitted.

Payment declinedWe couldn’t process your payment. Please update your payment method.

Policy overviewCoveragesClaimsPaymentsDocuments

Dwelling Protection

Helps protect the place you call home.

✓ Active

Policy number *

Enter policy number

Your policy number is on your declarations page.

✓Paid◷PendingiIn review!Action needed□Draft▣Archived

Typography

Display 1Bold · 40 / 48

Heading 2Semibold · 28 / 36

BodyRegular · 16 / 24

Color tokens

Navy
#102A43Insurance Blue
#1D5FA7Bright Blue
#2F7CC0Red
#C82032Pale Blue
#EAF2F8Warm Ivory
#F7F3EC

The opportunity

The work required two kinds of stewardship: maintaining live systems and shaping the enterprise system still being built.

My Account and Homesite were established production systems with real product constraints. EDS was a separate, developing foundation intended to create greater consistency over time.

I directly managed the production token systems supporting My Account and Homesite, keeping more than 100 foundational, semantic, and component-level decisions coherent across shipped experiences.

Separately, I completed or refactored 23 of 27 planned EDS tokens and architected or enhanced 28 of 45 reusable components, supported by documentation, accessibility requirements, and a governed contribution process.

100+production tokens governed

23/27planned EDS tokens

28/45EDS components

2production systems

Challenge

Live product systems and an emerging enterprise foundation needed clear boundaries.

Homesite

Partner flexibility

The production system needed to support partner experiences, brand expression, and established implementation contexts.

Teal themeLocal namesExisting patterns

Before≠Duplicated decisions
Inconsistent naming
Unclear ownership

My Account

Brand consistency

The production system needed recognizable American Family brand language and dependable interaction behavior across account workflows.

Blue themeBrand termsAccount patterns

The design question

How might I keep two live systems dependable while translating the strongest shared decisions into an enterprise foundation still taking shape?

System audit

I started with the patterns teams were already using.

Inventory

Collected existing colors, type styles, spacing values, components, variants, and implementation patterns.

Compare

Mapped equivalent concepts that used different names, values, or interaction behavior across teams.

Separate

Distinguished shared structural decisions from the foundations that needed to remain brand-specific.

Prioritize

Focused the first system release on high-frequency patterns with the greatest consistency value.

Pattern inventoryRepresentative reconstruction

PatternHomesiteClaimsSystem decision

Primary actionpartnerBlue / 600brandBlue / defaultAlias → action.primary

Error statusdanger / basealertRed / 500Alias → status.critical

Card surfacesurface / raisedcontainer / whiteNormalize elevation + border

Field spacing12px / 16px16px / 24pxAdopt 8px spacing scale

Key finding

The teams did not need identical brands. They needed shared semantics, predictable component behavior, and an explicit place for brand variation.

Token architecture

Translate brand decisions into a structure code can understand.

Reference values

blue.600 · space.300 · radius.md

→

Semantic tokens

action.primarysurface.raisedstatus.critical

Purpose before appearance

→

Brand themes

HomesiteAmFam

Same role · distinct expression

→

Components

ButtonFieldAlert

Tokens linked to behavior

Design tokenaction.primary.background

→

Theme value{brand.blue.600}

→

Component propertyButton / filled / default

The naming model became the contract: designers could reason in intent, while engineers received stable, implementation-ready values.

Component architecture

Build the rules once, then make the right behavior easy to reuse.

Enterprise UI library

FoundationsComponentsPatternsGuidance

28 of 45 components

Button

PrimarySecondary＋ Icon

6 variants · 3 sizes · 5 states

Text field

Policy numberEnter policy numberHelper text

Label · input · helper · validation

Status

✓ Paid◷ Pending! Action

Color + icon + text

Alert

Action neededReview this item to continue.

Info · success · warning · critical

Card

Dwelling Protection

Coverage for the place you call home.

Active

Content slots · actions · status

Tabs

OverviewDetailsDocuments

Keyboard navigation · overflow

Consistency

Shared anatomy

Every component documented structure, variants, states, responsive behavior, and content guidance.

Accessibility

Built into the definition

WCAG requirements, focus order, labels, contrast, and non-color status cues traveled with the component.

Extension

Clear boundaries

Teams knew when to configure, when to compose, and when a new contribution belonged in the shared library.

—

Design to code

A strong Figma library was not enough. The system also had to work in code.

Design foundations

Variables, styles, naming, and component properties.

→

Token files

Structured values prepared for implementation.

→

MUI + Material 3

Shared semantics mapped to practical engineering structures.

→

Product use

Reusable patterns applied across insurance workflows.

Partnership in practice

I worked directly with product and engineering to prototype patterns, review technical feasibility, supply token files, and resolve design-to-code gaps before they became product inconsistencies.

Governance

A library becomes a system when teams know how to change it.

01Identify
Document a recurring product need.
02Propose
Show use cases, anatomy, and system fit.
03Review
Evaluate design, accessibility, and engineering impact.
04Validate
Test variants, states, and real product contexts.
05Publish
Release with documentation and usage guidance.

Contribution guidelines

Make proposals comparable.

A shared template clarified the problem, evidence, component scope, states, and expected impact.

Quality standards

Review against the same bar.

Accessibility, content, responsiveness, theming, and code feasibility were explicit—not implied.

Usage guidance

Support better decisions.

Documentation explained when to use a component, when not to, and how it could be extended responsibly.

06 · Outcome

Production stayed grounded while the enterprise foundation became more complete.

More than 100 production tokens kept My Account and Homesite connected to the decisions their shipped experiences depended on.

In parallel, the EDS work advanced 23 of 27 planned tokens and 28 of 45 components, with clearer accessibility expectations, implementation guidance, and contribution rules.

—

Reflection

The most valuable outcome was not a component. It was shared understanding.

The components made consistency visible. The deeper value came from helping teams name decisions, evaluate exceptions, and carry brand intent into code in the same way.

That shared approach turned a library of reusable parts into something teams could confidently maintain and extend.