alight worklife design system

CLIENT

Alight Solutions

PROJECT

Enterprise Design System

MY ROLE

Product Design Lead

TEAM

9 direct reports, 35+ designers supported

YEAR

2020-2026

ENTERPRISE DESIGN SYSTEM

Alight Worklife Design System

I led the design system work connecting brand and product across Alight’s HR platform, serving 36M+ users. I brought Design, Product, and Engineering together around shared components, governance, and a clearer way to request and review work.

The platform supported benefits experiences for 70% of the Fortune 100. Our job was to give product teams a consistent foundation they could use as the platform grew.

Product Design Lead · Design System · Alight Solutions · 2020–2026

The challenge

Restructuring removed design specialties while the platform continued to grow. We needed a consistent way to make decisions and avoid rework across product teams.

The approach

I established governance, a fidelity decision framework, and structured intake so teams could agree on requirements and effort before work began.

The impact

40%

Less design rework, with fidelity decisions agreed during intake instead of being revisited mid-project.

I.3

Context & Constraints

We supported several product lines within a distributed, Product-led organization. As teams and priorities changed, we needed shared standards that people could use without relying on the design system team for every decision.

The team and scope 

Design systems leadership reported into Product.
Our distributed team supported several product lines, with specialized roles including accessibility experts. Long-standing partnerships helped us retain context as the organization changed.
The work included the AWLDS interface, modal guidance, and fidelity and intake frameworks.

Tools we worked with 

Figma for design and prototyping, Jira for intake and backlog management, Storybook for coded components, and Zeroheight for system documentation.


awlds-zh
awlds-getting-started
What this meant for the system

The guidance needed to work without me in the room. I focused on clear, shareable frameworks that teams could use on their own.


Research & Discovery

Audits and stakeholder interviews pointed to four recurring problems.

Scope changes during delivery

Product and Engineering sometimes requested more design detail mid-project without revisiting the estimate.

Different expectations of fidelity

Stakeholders did not have a shared way to distinguish fidelity levels or understand the effort each required.

Inconsistent modal patterns

Teams were creating modals and dialogs without shared guidance on interaction patterns and accessibility.

Requests entering the backlog too early

Without a formal intake process, design system requests could reach the backlog before requirements were clarified.

What we found

Building composites from core primitives (master components) kept patterns consistent and made the system easier to maintain. We needed to make the effort behind those decisions clear before work began.

Strategic Framework

I developed a fidelity decision matrix to help teams agree on the level of design detail and effort a project needed.

Low fidelity

Wireframes and basic layouts: 2–4 hours.

Medium fidelity

Styled mockups and basic interactions: 8–16 hours.

High fidelity

Polished UI, detailed interactions, and animation: 24–40+ hours.

We also formalized intake so requests included the details needed before backlog review:

  • Business impact and measurable goals
  • An agreed fidelity level
  • Accessibility requirements
  • Complexity and an effort estimate
Read more about the intake process here. 

Agree on fidelity before work begins

We documented fidelity decisions in the ticket during intake. If the work needed a higher level of detail later, we treated that as a scope change and revisited the estimate.

Design System Architecture

We organized the system into four levels, so teams could build on shared foundations rather than start over for each product.

Foundations

Design tokens, typography, color, and spacing.

Core components

Buttons, inputs, and basic layouts.

Composite components

Forms, data tables, and navigation built from core components.

Patterns

Shared approaches to complete workflows, such as login and dashboards.

Build on what is shared

Building composites from core primitives (master components) kept patterns consistent and made the system easier to maintain.

A product brand built to scale
As Alight Worklife expanded across products, partner experiences, and acquired businesses, teams needed flexibility without creating disconnected identities. I helped establish a governed product-brand architecture with two extension models, supported by construction rules, downloadable assets, and usage guidance.
Implementation & Adoption

How we rolled it out

1. Foundations and core components

We started with tokens and core components over the first three months.

2. Governance and documentation

The next two months focused on governance frameworks and documentation.

3. Patterns and adoption

We continued developing more complex patterns and supporting teams as they adopted the system.

Helping teams answer their own questions

Office-hours attendance dropped 40% after three months as the documentation gave teams more of what they needed to work independently.

Challenges & Tradeoffs

Making intake useful to teams

Some product teams initially saw intake as extra bureaucracy. I framed it around protecting everyone’s time: clearer requirements for Engineering, more predictable timelines for Product, and fewer mid-project changes for Design.

We made intake a prerequisite for design and engineering work, so requests were scoped before entering the backlog.

Keeping the work moving through restructuring

Changes to the organization created context switching and loss of institutional knowledge. I focused on documentation and standalone frameworks that teams could reference without needing me to explain them each time.

What helped the system scale

Shared guidance gave teams a way to make consistent decisions without bringing every question back to the design system team.

I.4

REFLECTION

What I learned

Start intake earlier

I introduced structured intake in the second year. By then, ad hoc requests had already shaped expectations and made governance harder to change. Starting with shared requirements, fidelity, accessibility, and effort would have made delivery more predictable from the beginning.

Accessibility improves every decision

Accessibility experts changed how we evaluated the work. Their perspective gave Design and Engineering a shared filter for challenging assumptions, considering edge cases, and making more deliberate choices. Accessibility raised the entire team’s standard—not just our compliance baseline.

Build guidance that works without you

The system became stronger when teams could make consistent decisions without depending on the design systems team for every answer. Shared naming, reusable components, and clear documentation gave people the confidence to move independently.

Outcomes

Multiple product teams adopted the system across a platform serving 36M+ users. From 2020 to 2026, design rework fell by 40% and design capacity increased by 35%.

Shared standards and intake helped teams agree on the work upfront, with clearer expectations and a more consistent way to deliver. 

The foundations and architecture I built are still in use today.

The team

DESIGN

3 Designers

COPY

1 Writer

A11Y

2 Accessibility Experts

DEV

3 Engineers

Automating Design System Governance
Design Systems · AI · Automation

Automating Design System Governance
Automating Design System Governance
Design Systems · AI · Automation

I love collaborating, 
so go on.
 Reach out.
 

CONTACT

FOLLOW

RESUME

available upon request

FOUNDER WORK

© 2026 Russell Beaver. All rights reserved.