Auditing an Enterprise Design System and Proving It Could Power a Full Product Modernization
I spent my internship at Allegion, a global leader in security products, embedded on a four-person cross-functional pod tasked with a single question: could the company's internal, Material Design 3–based component library realistically support one of its larger, older enterprise software products — not just the newer, smaller apps it was originally designed around? My role bridged UX design and front-end engineering: auditing the design system itself, designing and building the components it was missing, and using AI-assisted workflows to help rebuild a modernized, on-brand version of the product end-to-end.
Because this work involves unreleased Allegion products, specific product and internal system names have been generalized throughout this case study. The scope, methods, and results described are accurately represented.
A mismatch between a growing internal design system and an aging flagship product set up the challenge for the summer
Components in the design system audited against usability heuristics
Total usability findings identified across the library
Interns — two designers, two engineers — sharing one pod and one repo
The design system had been built and validated against a handful of newer, smaller products. Meanwhile, one of the company's established enterprise applications was still running years-old visual and interaction patterns with no path to the modern brand. Before anyone could commit engineering time to a full rebuild, we needed to know whether the design system could actually hold up at that scale — and if it couldn't yet, exactly where it would break.
My design partner and I independently evaluated the full component library — 30+ atoms, molecules, and organisms — against Nielsen's 10 usability heuristics and Material Design 3's quality principles, adapted into six system-specific themes covering documentation, consistency, clarity of language, flexibility, contextual guidance, and inclusive design. We then synthesized our two independent evaluations into a single report, rating every finding on a four-point severity scale.
Individual findings kept tracing back to the same handful of systemic gaps
Several core components could be freely resized or stretched in the design file with no minimum or maximum constraints, which broke compliance with the system's own underlying spec and let every team implement the same component slightly differently.
Lock frame dimensions anywhere the spec defines a fixed size, and add explicit min/max constraints anywhere flexible sizing is intentional.
Documentation consistently claimed desktop and cross-platform compatibility, but almost every visual example only showed a mobile layout, leaving designers no way to verify how a component should adapt to a larger screen.
Require both a mobile and a desktop example frame for every component, and explicitly note when the two layouts are meant to be identical.
The same concept — emphasis levels, state names, sizing properties — was labeled differently from component to component, forcing designers to interpret intent rather than act on clear guidance.
Create a shared terminology glossary and enforce it consistently across every component page.
Components with several visual variants rarely explained when or why a designer should choose one over another, which was especially confusing for less experienced users of the system.
Pair every variant with a one-sentence use case and at least one in-context visual example.
With the audit complete, the second half of the internship was about putting the findings to work — filling the system's gaps and using it to rebuild the legacy product end-to-end.
Halfway through the internship, two software engineering interns joined the pod to connect the rebuilt front end to the product's existing backend — which meant rethinking how design and engineering work were structured together.
Our prototype and the engineers' backend work started out in separate repositories with incompatible folder structures — so we migrated the frontend work into their sandbox repo and re-architected around one shared structure. That let a designer and an engineer pair up on individual pages and go back and forth on implementation in real time, instead of working from a static handoff.
By the end of the internship, the rebuilt product wasn't just a proof of concept anymore — it was evidence that the design system could support Allegion's larger, more complex products, not only the newer ones it had originally been built around.
Nearly the entire rebuilt front end ran on the shared component library, up from effectively none in the legacy product.
The pod built the large majority of the product's front-end pages, dialogs, and modules, and connected most of them to live backend data before handoff.
The original product took over a year to build. This modernized proof of concept — audit included — took twelve weeks.