✦ design-system · albertsons-uds · 2023 to 2025

Albertsons

Unified

Design System

Scaling design consistency across 14 business units, building the token architecture, components, and documentation that unified Merchandising PODs inside Albertsons.

role"UI / UX Designer"// component design, tokens, docs

components30+// figma variants, all states

teams_served14// business units onboarded

eng_velocity"30%+"// faster on fully adopting teams

wcag_level"AA"// all components pass by default

View in Figma ↗ Read Case Study ↓

uds / tokens / global.json

Color / Brand

color.brand.navy

#0B1F4A

color.brand.primary

#1B6EBB

color.status.success

#22C55E

color.status.error

#EF4444

color.status.warning

#FB923C

Spacing / Scale

spacing.01 to spacing.12

4 to 48px

Components

Button

Input

Calendar

Alert

Badge

Company

Albertsons ↗

My Role

UI / UX Designer

Collaborators

2 Designers + 3 Devs

Timeline

2023 to 2025

Context & My Role

Part of a small team building a system at scale

I worked as a UI/UX Designer on the Unified Design System team, alongside one other designer and three front-end engineers. I owned the full design execution: token architecture, component design with all states, usage docs, accessibility reviews, and Storybook alignment.

Before UDS, every team designed their own UI from scratch. Buttons had six different styles across the product, colors were hardcoded everywhere, and there was no accessibility standard at all. You could see the fragmentation the moment you opened any of the Figma files.

Problems I was solving

No shared component library. Every POD designed buttons, tables, and modals independently in multiple incompatible versions.

Zero token architecture. Colors, spacing, and type were hardcoded values scattered across Figma files and code repos.

No accessibility standard. Most flows failed WCAG AA with no audit process in place to catch regressions before shipping.

Slow design-dev handoff. Engineers rebuilt the same UI patterns from scratch every sprint, wasting time on both sides.

Design Goals

What I set out to build

These four goals shaped every decision I made over the two years I worked on this.

Single Source of Truth

One Figma library, one token file, one documentation site. Any designer or engineer could pick up the system and ship consistent UI without constantly second-guessing themselves.

Consistency

Token-First Architecture

Every color, spacing value, radius, and shadow referenced a named token. One update at the top cascades to every component automatically.

Scalability

Accessibility by Default

WCAG AA compliance was built into the component layer from the start, not added later. Any team using UDS gets accessible UI without doing anything extra.

Accessibility

Ship Faster Together

Cut the design-to-dev gap. Annotated handoffs, Storybook parity reviews, and clear docs meant engineers could build with confidence and fewer questions.

Velocity

My Design Process

How I worked sprint to sprint

My sprint work followed a repeatable loop. Understand the POD need, design the component, write the docs, validate with engineering, release, then audit in production.

POD Intake and Requirement Review

Discovery

When a product team needed a new component, I joined their intake sessions to understand the use case. Then I figured out whether we could extend something we already had, or whether we actually needed something new.

Component RFCFigma AuditPOD Sync

Explorations and Variant Design

Design

I explored two or three directions for each component, making sure I had every state covered: default, hover, focus, active, error, and disabled. WCAG contrast checks happened before anything went to critique.

Figma VariantsAuto-layoutWCAG Checks

Token Binding and Library Publish

System Integration

Once a component was approved, I bound every visual property to the token system using Figma Variables, then published to the shared library.

Figma VariablesToken MappingLibrary Publish

Documentation

I wrote usage guidelines for every component, covering when to use it, when not to, anatomy labels, dos and don'ts, and accessibility notes. All of it went to the UDS Docs site and Confluence.

UDS Docs SiteConfluenceDo / Don't

Engineering Handoff and Storybook Review

Collaboration

I handed off with annotated Figma specs covering spacing values, token names, and edge cases. Then I reviewed the Storybook implementation side by side with the engineers.

Figma AnnotationsStorybookDesign Parity

POD Audit and Compliance Reviews

Quality Assurance

After release I ran quarterly audits of screens built by each POD. I checked typography, spacing, color, and component usage against the UDS checklist, then flagged anything off and worked directly with the POD designers to fix it.

Audit ChecklistsUDS ComplianceDesign Reviews

Figma Variables

Token architecture

Built the full three-tier token hierarchy: global primitives, semantic aliases, and component-scoped values. Token names were agreed with engineering upfront to match CSS exports exactly.

Storybook

Engineering parity

Sitting with engineers and reviewing Storybook against Figma together, component by component, was worth more than any redline spec I could have written.

WCAG 2.1 AA

Accessibility standard

Getting focus states, contrast ratios, and touch targets right from day one saved the whole team from expensive accessibility audits later.

Components from the Albertsons UDS

Real components I designed and documented

Each component was designed in Figma with all states, published to the shared library, and reviewed against a Storybook counterpart by front-end engineers before release.

Foundation · Interactive

Button

Primary, secondary, ghost, and icon variants with large, medium, and small sizes, plus all interaction states. Every property token-bound.

Variants

Sizes

States

Form · Data Entry

Input Field

Default, focus, error, and active states with label, helper text, and inline validation. Border radius 8px, every property token-bound.

Feedback · Status

Badge and Status Chip

Semantic status indicators for item states, workflow stages, and notification counts. Consistent color-meaning mapping across every Merch screen.

Feedback · Notification

Alert and Toast

Info, success, warning, and error states. Dismissible, with icon slot and action link. All WCAG AA compliant by default.

Data Entry · Scheduling

Date Picker / Calendar

Used across promotion scheduling, supplier SLA deadlines, and reporting date ranges. Supports single date, date range, and keyboard navigation.

Design Tokens

Building the single source of truth

Platform-agnostic variables for color, typography, spacing, and shadows. Every color, spacing step, radius, and shadow in every component was token-bound and published to the shared Assets panel. A brand update in one place cascaded everywhere instantly.

Color Tokens

color.brand.navy

#0B1F4A

color.brand.primary.500

#1B6EBB

color.feedback.success

#22C55E

color.feedback.error

#EF4444

color.feedback.warning

#FB923C

color.status.submitted

#A855F7

Spacing Tokens

spacing.01

4px

spacing.02

8px

spacing.03

12px

spacing.04

16px

spacing.06

24px

spacing.08

32px

spacing.12

48px

Typography Tokens

Display / 800

type.display.lg · 24px · weight 800

Heading / 700

type.heading.md · 18px · weight 700

Body / 400

type.body.md · 14px · weight 400

Label / 500

type.label.sm · 12px · weight 500

Code / Mono

JetBrains Mono · 11px

Elevation / Shadow Tokens

shadow.xs

shadow.sm

shadow.md

shadow.lg

shadow.focus

Before and After

What changed when UDS was applied

The Merchant and Supplier Portal was the first major test of UDS in production. I rebuilt key MSP screens using UDS components and tokens. The difference was noticeable right away, in quality, in speed, and in how users responded.

Before UDS

Legacy / 1WorldSync

Third-party platform with no Albertsons design ownership or token system

Inconsistent colors across green, gold, blue and red with no shared meaning

No shared nav shell, every section had its own header

Flat, data-heavy layout with no visual hierarchy or type scale

Fragmented status indicators and no component system to speak of

After UDS

Unified / Accessible

Owned Albertsons product with full design system control

Dark navy sidebar with light content area, clear hierarchy from the UDS shell tokens

One consistent blue (#1B6EBB) used semantically throughout, no exceptions

Data table with UDS typography, properly scannable and accessible by default

Stat cards with semantic color icons that carry the same meaning across every POD

Impact and Results

What the system delivered

These numbers came directly from the design work. The MSP redesign I contributed to became the proof that convinced leadership to keep investing in building out the system.

14+

Business units onboarded, all consuming the same shared Figma library and component codebase

76%

Supplier onboarding SLA reduced from 21 days to 5 days after UDS rollout on the MSP

30%

Engineering velocity increase on fully adopting teams, less UI rework, more time on product logic

WCAG accessibility compliance across all components, built in from day one not retrofitted

Flagship: Merchant and Supplier Portal

The MSP rebuild using UDS components gave leadership the numbers they needed. Error rates dropped 23%, NPS went up 15 points, and supplier onboarding time fell from 21 days to just 5.

$500K+ in Hard Savings Per Year

Less duplicate work, fewer rework cycles, and engineers spending less time rebuilding UI. The system paid for itself in the first year across 14 business units.

Key Learnings

What this project taught me

Two years on this project taught me things that don't show up in any metric.

🧱

Systems thinking changes how you design

When you're designing for a system, you're not designing a single screen. Every decision gets consumed by 14 teams and hundreds of engineers. You have to be much more deliberate about everything.

🤝

Design-engineering alignment is the real work

The hard part was never the component design itself. It was keeping Figma and Storybook in sync as the sprints piled up. Sitting with an engineer and reviewing things together was always worth more than writing a perfect spec.

📖

Documentation is a design deliverable

A component without usage guidelines will always get misused. I learned to write the docs as part of the component work, not after it. The do's and don'ts, anatomy labels, accessibility notes, all of it.

♿

Accessibility built-in beats retrofitted

Designing WCAG compliance in from day one, focus states, contrast ratios, and touch targets, saved the team from costly audit cycles and gave every POD a free accessibility baseline just by using the library.

Summary: what I built and owned

I owned the design work that made the system real and usable. Working with a small team, one other designer and three engineers, we shipped something that scaled across an entire enterprise. One component at a time, one token at a time.

Designed and documented 30+ Figma components with full variant states

Built the complete token architecture: Color, Spacing, Type, Radius, Shadow

Ran quarterly POD audit and compliance reviews across Merch screens

Directly redesigned MSP screens using UDS, the executive proof-point

Authored all usage guidelines for the UDS Documentation Website

Collaborated with 3 FE engineers on Storybook parity and handoffs

Albertsons Unified Design System