Albertsons Companies
Building a design system that could sustain itself.
From fragmented merchandising experiences to a shared platform: the people, governance and funding behind UDS.
AI leadership noteKeep the design rules with the code
Original approach
The Merchant & Supplier Portal applied UDS to global navigation, dashboards, task lists and workflows. It connected the platform investment to a concrete merchandising experience.
What could change today
Use the Agentic Design System tool to capture approved Figma variables and component guidance through an agent with Figma access. Publish the reviewed tokens and a Markdown contract beside each component. Give design ownership of intent and engineering ownership of behavior.
Workflow excerpt. The numbered steps show the same part of the journey in each version. The full project includes work beyond this comparison.
Original workflow
- Understand fragmentation
- Establish foundations
- Apply in delivery
- Sustain & evolve
Proposed workflow with AI
- Have an agent inventory duplicate patterns for designers to verify.
- Turn approved Figma tokens and behavior into a component contract.
- Generate a Button change and test its states in a real interface.
- Give owners a versioned review process for future changes.
Team and responsibilities
The 25+ direct reports describe the wider organization. For a pilot, a component designer and a front-end engineer could own one Button change together, with an accessibility reviewer checking the result. Measure review effort before expanding the pilot.
How to test the change
Pilot one Button change. Compare its hover, focus, disabled and loading states with the approved design and check keyboard use before merging.
Figma: connecting design context to agents
Agentic Design System tool01 / The problem
What needed to change?
The customer need.
Product teams need a foundation they can adopt in delivery; merchants and suppliers need predictable interactions across fragmented tools.
Merchandising experiences had grown across different stacks, patterns and documentation. Supplier work moved through SharePoint, email and legacy tools. The repeated interpretation between design and implementation made a common experience difficult to sustain.
The leadership problem extended beyond a component library: teams needed a shared foundation they could adopt in real delivery, a way to resolve competing needs, and a model for supporting the system after its first release.
02 / My accountability
Scope of responsibility.
Built UDS from the ground up, chaired the Design System Council and led a multidisciplinary organization of 25+ direct reports. Shaped $7M–$13M in investment plans within a shared $52M director-level portfolio, alongside Finance, Strategy and executive stakeholders.
Responsibilities included platform direction, prioritization, contribution governance, adoption and team development. Designers, researchers, engineers and product partners contributed the work. The broader portfolio was shared; the $52M was managed jointly.
The constraint to work through.
The system needed ownership, contribution rules, support and sustained funding alongside its tokens and components.
03 / Evidence & discovery
What informed the work.
Fragmented workflows and inconsistent patterns defined the initial platform challenge. As teams applied UDS in production, adoption learnings informed the next backlog: core components, themes, documentation and a demonstration application.
Aligned design-system priorities with merchant workflows. The Merchant & Supplier Portal gave teams a concrete application of shared navigation, dashboards, task lists and components, and a basis for discussing the next investment.
Understand fragmentation
Identify disconnected workflows, patterns and documentation.
Establish foundations
Shared tokens, components, templates and usage guidance.
Apply in delivery
Use the Merchant & Supplier Portal as a production proof point.
Sustain & evolve
Contribution governance, releases and participating-team funding.
04 / Leadership decisions
Where my judgment mattered.
Treat the system as an internal product.
Established common foundations, reusable components, usage documentation and a maintained roadmap. A central documentation hub made standards and release information available to teams.
Leadership implication: platform work needs ongoing ownership and support capacity, alongside feature delivery.Give contributions a clear path to production.
The component lifecycle covered request/RFC, UX and accessibility review, implementation, QA, versioned release, telemetry and deprecation. Chaired the council responsible for shared standards.
Leadership implication: a contribution model must protect coherence while allowing product teams to participate.Use adoption to inform investment.
Prioritized business impact and delivery capacity, with foundational components ahead of isolated additions. Merchant & Supplier Portal work became a proof point for continued investment and expansion.
Leadership implication: a useful production application makes a stronger investment case than a library presented in isolation.Connect adoption with sustainable support.
Participating teams funded design-system expertise and delivery support through internal chargeback. The system became self-sufficient rather than depending only on a project allocation.
Leadership implication: internal funding sustains services; it is not evidence of company revenue or audited net savings.The shared foundation
A system teams could understand and apply.
Shared tokens connected visual decisions to reusable components. Documentation brought usage, specifications, guidelines and implementation properties into one reference.
02 / Component guidance
From a button to a shared way of building.
The documentation structure gives teams a consistent route through overview, specifications, guidelines, playground and properties.
The same structure makes the library easier to learn, review and maintain as it grows.
05 / Application & people
How the work reached delivery.
The Merchant & Supplier Portal applied UDS to global navigation, dashboards, task lists and workflows. It connected the platform investment to a concrete merchandising experience.
Team development was part of the operating model. Gave a designer working primarily in Pricing a stretch assignment in global navigation, supported by regular QA feedback. His received LinkedIn recommendation describes expanded skills and coordination across the US and India.
Before UDS
With UDS
06 / Outcomes & attribution
What changed, and how to read it.
UDS became the company-wide standard for 100+ teams, with participating-team funding supporting its ongoing operation.
The portal program reduced the supplier-onboarding SLA target from 21 to 5 days, reduced errors by 23% and increased NPS by 15 points. These were cross-functional program outcomes. The SLA measure is a target change, distinct from actual elapsed cycle time.
The system also informed newer AI-assisted contribution workflows. The UDS adoption count must not be read as the number of teams actively using those newer workflows.
Business value.
Participating-team funding connected ongoing support to adoption, helping UDS operate as a sustained platform service rather than a one-time component delivery.
07 / Reflection
Lessons for future projects.
My leadership takeaway is that shared design quality needs an operating model: ownership, contribution rules, adoption support and continued funding. The visual library is only one part of the result.
For a stronger value review, pair adoption with component reuse, support demand and comparable delivery-quality data. That would show whether the platform is helping teams over time, beyond the count of teams using it.
Measurement notes
UDS adoption shows the scale of the shared foundation; the portal outcomes belong to a broader cross-functional effort. The onboarding measure is a service-level target, not measured elapsed cycle time.
Let’s talk about your next chapter.
Exploring Senior Director, Head of Design and VP opportunities.