American Family Insurance

UX Design Systems

Project Summary


Design teams and partners struggled with fragmented user experiences and inefficiency, so we built a unified UX design system in Figma grounded in Material Design 3, atomic design, React, WCAG, and UX best practices. Structured from simple elements to modular components, it improved consistency, reusability, and scalability while streamlining collaboration and onboarding.


The system enhanced workflows, reduced errors, and fostered collaboration, remaining scalable with growth to maintain brand consistency and provide a lasting foundation for design excellence.


Timeline


9 months

Collaboration


Product Manager 

Product Owner

Developer

Content Specialist

UXD (7)

Tools


Figma

Axure

Miro

Zoom

Usertesting.com

Jira

Confluence

My Role


UX designer
Research Lead

I believe that a UX design system works best when it supports both enterprise standards and team-level realities.

I worked on UX design systems at two very different scales: an enterprise-wide system that required shared governance across teams, and a smaller, retention-focused system designed for speed and iteration.


Enterprise-wide UX design system

  • Emphasized consistency, accessibility, and long-term maintainability
  • Required shared governance and cross-team alignment
  • Supported multiple products and contributors at scale
  • Reduced fragmentation and established a common design language


Retention-focused UX design system

  • Prioritized speed, flexibility, and rapid iteration
  • Enabled faster experimentation and delivery within a smaller team
  • Adapted quickly to evolving user and business needs
  • Focused on solving specific problems with minimal overhead


Lessons I learned from working across both systems


  • When strong governance is essential and when lightweight systems work better
  • How enterprise standards can inform smaller systems without slowing them down
  • How insights from fast-moving teams can strengthen larger systems over time

Working across both scales gave me a strong understanding of when to apply structure and when to allow adaptability, and how each approach can inform the other to create systems that are both resilient and practical.

Enterprise UX design system example: Breadcrumbs


Within a large, cross-functional team, I served as both a contributor and a steward of the enterprise UX design system. I collaborated on shared standards and governance while taking ownership of individual patterns as opportunities arose.


My work on the breadcrumbs pattern is one example of how I led research, design, and refinement for a component while ensuring alignment with system-wide usability, accessibility, and consistency goals.

Five personas arranged in a group

A system that adapts across multiple teams and operating companies


The components were designed to support AmFam and its operating companies by accommodating brand-specific color systems and variations, while remaining flexible enough to include options that some teams could toggle off based on their product needs.




For example, I approached the breadcrumbs pattern with a research-first mindset, reviewing extensive UX best practices to validate when breadcrumbs are appropriate, how they should communicate hierarchy, and how they should behave across different contexts. These findings guided the design toward a pattern that supported complex navigation while aligning with accessibility standards and system-wide consistency.

Some of American Family Insurance's operating companies the design system was required to serve

Components of an enterprise-wide UX design system


Research


Design decisions were grounded in established best practices rather than personal opinion.


Research focused on:

  1. Widely adopted enterprise design systems
  2. Platform conventions
  3. WCAG accessibility guidelines


Widely adopted enterprise design systems

I explored the following widely adopted and most commonly used design sytems to validate component design best practices for our complex insurance workflows.



Material Design 3

Reason for Review

  • Modern interaction patterns and component standards for Android and web
  • Emphasis on hierarchy, adaptability, and accessibility
  • Developers most comfortable with components

Referenced for

  • Navigation patterns and hierarchy
  • Responsive behavior across screen sizes
  • Accessibility considerations aligned with WCAG standards


IBM Carbon Design System

Reason for Review

  • Focuses on data-heavy interfaces, and scalability
  • Cited for governance and pattern rigor


Referenced for

  • Enterprise navigation

Atlassian Design System

Reason for Review

  • Examples of component evolution over time

Referenced for

  • Complex navigation
  • Workflow-heavy products


Apple Human Interface Guidelines



Reason for Review

  • Sets iOS and macOS interaction expectations
  • Emphasis on clarity, hierarchy, and native behavior

Referenced for

  • mobile navigation
  • hierarchy platform conventions

Microsoft Fluent Design System



Reason for Review

  • Used across Windows, web, and enterprise tools

Referenced for

  • cross-platform consistency

US Web Design System

Reason for Review

  • Government-backed, accessibility-first
  • Strict WCAG compliance


Referenced for

  • accessibility standard

Salesforce Lightning Design Systems


Reason for Review

  • One of the earliest large-scale enterprise design systems
  • Pattern consistency across many products
  • Emphasis on reusability


Referenced for

  • Enterprise components
  • UI patterns


In keeping with the breadcrumbs example, I was researching to validate best practices and platform conventions listed below before designing the breadcrumbs pattern:


  • When breadcrumbs are appropriate
  • How hierarchy should be expressed
  • How patterns scale across products and teams
  • How accessibility is handled in real-world systems

Platform convention research

In addition to industry best practices, I reviewed platform conventions to align the breadcrumbs pattern with established web and enterprise navigation behaviors. Leveraging familiar interaction patterns reduced learning effort and user error.



These conventions gave me an idea of

  • What patterns are commonly used
  • How they behave
  • When they are appropriate or inappropriate

And this ensured:

  • Breadcrumbs behaved as users expected
  • The pattern didn’t conflict with native navigation
  • The system scaled across desktop and mobile contexts

This mattered because:

  • In an enterprise system, users move between many tools and surfaces
  • Breaking conventions increases cognitive load
  • Consistency across platforms builds trust

Web / Desktop


  • Breadcrumbs appear near the top of the page, below global navigation
  • Breadcrumbs reflect hierarchy, not history
  • The current page is shown but not clickable
  • Separators are visual, not read aloud by screen readers


Mobile


  • Breadcrumbs are often omitted due to space constraints
  • Hierarchy may be shown through back navigation instead
  • If breadcrumbs exist, they are simplified or collapsed


Android (Material Design)


  • Navigation emphasizes clear hierarchy and predictable patterns
  • Breadcrumb-like behavior is often handled through app structure and back behavior
  • Components follow strict spacing, typography, and accessibility rules



iOS


  • Hierarchy is typically conveyed through navigation stacks
  • Breadcrumbs appear implicitly in navigation titles or back buttons
  • Consistency with system navigation is prioritized over custom patterns


WCAG Mapping

While not required by WCAG, accessible breadcrumbs support multiple WCAG principles by improving navigation, orientation, and predictability across complex content hierarchies. If breadcrumbs are present, they must be accessible.

When implemented thoughtfully, breadcrumbs support WCAG goals by improving orientation, navigation, and predictability—especially in complex, enterprise systems.


Some of the WCAG standards the progressive reveal improvements redesign met.


Our own WCAG component checklist

Perceivable


WCAG 1.3, 1.4



  • Breadcrumbs expose page hierarchy in a structured, text-based way.
  • They help users visually and programmatically understand where they are.
  • Clear separation and readable labels improve perception for all users.


Why it matters
Users need to perceive their location in the system without relying on memory or visual layout alone.


Operable


WCAG 2.4, 2.4.7. 2.4.8

  • Breadcrumbs provide an additional navigation mechanism.
  • They support efficient backward navigation without repeated browser actions.
  • When keyboard accessible, they improve non-pointer navigation.
  • They help users understand where they are within a set of pages or content, which directly supports navigation and control.
  • They give users more than one way to locate content, supporting flexible navigation.



Why it matters:
Users need to move through content more efficiently, especially in deep hierarchies.

Understandable


WCAG 3.2, 3.2.3




  • Breadcrumbs reinforce consistent navigation behavior.
  • They help users anticipate where a link will take them.
  • Clear hierarchy reduces confusion and disorientation.
  • They behaves predictably across the experience so users don’t have to relearn patterns.


Why it matters:
Predictable navigation lowers cognitive load and reduces user errors.

Robust


WCAG 4.1

  • Proper semantic markup (for example, nav landmarks and lists) ensures screen readers can interpret breadcrumb structure.
  • ARIA attributes can further clarify relationships when needed.


Why it matters

  • Assistive technologies can accurately convey page position and navigation options.


Retention Pod UX Design System

A Different Scale, A Different System

Applying Systems Thinking at the Pod Level


In contrast to the enterprise design system’s emphasis on governance and shared standards, the retention pod design system required deep, hands-on problem solving within a tighter scope.


As the retention component lead, I built highly configurable components that supported complex, real-world retention scenarios, including state-specific bill pay rules, varying payment method eligibility, and multiple insurance product types. By embedding this complexity directly into reusable Figma components, the team was able to iterate quickly while accurately designing for all supported scenarios.

Why the System Needed to Change


Previously, designers spent significant time creating detailed mockups and duplicating work to communicate interaction states and component behavior. Many retention components had become overly complex, with hidden options that caused confusion and limited adoption. I addressed this by refactoring patterns into smaller, composable components and restructuring them so relevant properties and variants were visible and easy to toggle. Because no single configuration was used most often, this approach allowed designers to adapt components quickly without unnecessary rework.


By encoding interaction logic and edge cases directly into reusable Figma components, the system reduced the need for repetitive documentation and manual duplication. Designers were able to spend more time solving user and business problems rather than recreating interface mechanics, significantly reducing design effort and turnaround time for the retention team.


At a broader level, the UX design system improved workflows, reduced errors, and strengthened collaboration while remaining scalable as the organization grew. It maintained brand consistency across operating companies and provided a durable foundation for accessibility, design quality, and long-term system evolution, making the system easier to use in day-to-day workflows.




Before
When Everything Lives in One Component, you have

high complexity but low usability

After
When components work together, the result is a simplified structure with full capability

The more usable component,
iOS version

Sample of frame variety, native

Above: iOS, below: Android

Everything accounted for in the easier to use and understand, toggle-based redesign

Mobile-First Components

Designing for Android and iOS



Retention experiences were designed with mobile use as a primary context, recognizing that many customers manage payments and policies on the go. Components were built to support both Android and iOS, respecting platform-specific constraints and native interaction patterns while maintaining a consistent experience across products. This balance of consistency without sameness helped reduce friction in critical moments, making it easier for customers to complete tasks, manage payments, and stay engaged across devices.

Partnering with Engineering

From design intent to ARIA implementation


On the retention project, I partnered closely with engineering to support accessible implementation across multiple components and interaction patterns.


One example involved addressing cases where meaning was conveyed through spatial relationships, with labels positioned above or near values to imply context. While this worked for sighted users, screen readers announced the content in DOM order, causing values and labels to be read separately and out of context.


In these situations, I worked with developers to apply appropriate ARIA relationships so values were announced with their associated labels. This type of collaboration was part of a broader effort to ensure visual design intent, interaction behavior, and accessibility requirements were consistently reflected in the final implementation.

Design System Governance

Evaluating change at scale


I served as a subject matter expert within the enterprise design system, helping evaluate proposed changes to existing components and reviewing requests for new widgets. This work required balancing innovation with system integrity, ensuring that updates solved real product needs without introducing fragmentation or unnecessary complexity. By participating in design system reviews and voting on changes, I helped maintain consistency at scale while allowing the system to evolve in a thoughtful, intentional way.

A quick guide I created for submitting a pod component to the design system committee for consideration for addition to the DUX library

A Pattern of Practice


Design systems have been a recurring area of leadership throughout my career. Beyond the systems highlighted here, I’ve led and contributed to UX design systems in two prior roles, each with distinct organizational contexts and challenges.


Over time, lessons from earlier systems directly informed the later ones, shaping how I approach governance, accessibility, scalability, and day-to-day usability when designing systems that remain useful for the teams who rely on them.

Lessons I learned from working across both systems


  • When strong governance is essential and when lightweight systems work better
  • How enterprise standards can inform smaller systems without slowing them down
  • How insights from fast-moving teams can strengthen larger systems over time

Working across both scales gave me a strong understanding of when to apply structure and when to allow adaptability, and how each approach can inform the other to create systems that are both resilient and practical.

Final Outcomes and Impacts


Across both projects, the UX design systems improved workflows, reduced errors, and strengthened collaboration while remaining flexible enough to scale with organizational growth. The enterprise design system provided a shared foundation of patterns and components that maintained brand consistency across operating companies, embedded accessibility best practices, and supported long-term design quality and system evolution.


The retention pod design system delivered impact through speed and focus. By introducing shared, highly configurable Figma components, the team significantly reduced design effort and turnaround time. Designers no longer needed to create exhaustive mockups to explain interaction states and edge cases, as these behaviors were encoded directly into the components. This allowed the team to shift effort away from documentation-heavy production work and toward solving user and business problems.


Taken together, these projects demonstrate an intentional, context-aware approach to design systems—applying governance and structure where scale demanded it, and flexibility and speed where rapid iteration mattered most.The result was faster delivery, improved collaboration between design and engineering, and experiences that better supported both users and the business.