All projectsAllegion / Phoenix

One language. Many products.

Every Allegion product looked like it came from a different company.

My role
Co-Author, Sr. UI Designer
In collaboration
2 Design System Authors
Timeframe
November 2018 – September 2019
Focus
Design Systems · Enterprise UX
Published project overview · Allegion
The challenge

Every product looked like a different company.

Allegion absorbed legacy brands like Schlage, Von Duprin and LCN, each with over 100 years of history. As it shifted from manufacturing company to technology company, a wave of in-house software exposed a problem: every web property and app looked different.

The approach

Atoms first, then everything built from them.

As co-author of Project Phoenix, my partner and I studied what IBM, Google, Shopify and Salesforce were doing, and made the case to leadership that design improves ROI. Using Brad Frost’s atomic design, we built from the ground up: atoms (color, typography, spacing), molecules (buttons, inputs, toggles), organisms (navigation, forms, complex components).

  • Studied design systems including IBM Carbon and Shopify Polaris
  • An atomic structure: atoms, molecules, organisms
  • A token system for color, typography and spacing
  • A component library covering the standard UI patterns
  • Documentation and usage guidelines
  • A soft launch inside the company to gather designers’ feedback
What changed

One foundation, two real products.

Designers and developers worked in silos, rebuilding the same components differently each time. No shared language, no documentation. The result was longer development cycles and duplicated effort.

Designers adopted the system faster than we anticipated. Development teams had a single source of truth. It became the foundation for enterprise applications including Overtur and Access Management.

Evidence and limits

What the system made reusable.

Teams shared the same language and the same components, and later projects started from them instead of from scratch.

What shipped

A token system for color, typography and spacing; a component library covering the standard UI patterns, each with its states; documentation and usage guidelines; and a governance model for how the system changes.

What was observed

Designers took up the system faster than we anticipated, development teams worked from a single source of truth, and it became the foundation for Overtur and Access Management.

What this case doesn’t claim

A measured speed-up. The figures below were reported at the time without a published baseline or method.

Reported at the time, method not published: prototyping about three times faster; documentation for every component; shorter design-to-development handoff; more consistency across teams.

What’s next

Built to keep evolving.

Phoenix was built to keep evolving. The governance model we set up was there so the system could grow with the organization without losing consistency.

The principle I carry forward

A system earns adoption by being easier to use than to ignore.