Allegion’s designers and engineers lacked clear guidance for reusing Phoenix components, so I helped refine the documentation, and Allegion implemented our revised Lock Status interaction.
Role
UX Research
Design System Documentation
Documentation Testing
Timeline/Duration
Spring 2026
Team
7 UX Designers/Team B
Focus
Component Guidance
Documentation UX
Tools
Figma
Claude
ChatGPT
Expanding and Refining a Company-Wide Design System
Phoenix is Allegion's first company-wide design system, bringing shared styles, components, and guidelines together across its digital products.
Our seven-person UX team worked to expand Phoenix with reusable components from the Schlage app while improving the documentation supporting their implementation.
Following a shared research phase, we divided into two workstreams. Team A explored component redesigns, while Team B focused on refining documentation. As part of Team B, I worked on making component information, interactions, and usage guidance clearer for Allegion designers and engineers.
Useful Components Existed Outside Phoenix
Several UI components in the Schlage app had not yet been incorporated into Phoenix, limiting opportunities for consistent reuse across Allegion products.
At the same time, our design-system audit identified documentation gaps involving component specifications, interaction behavior, and usage guidance. Designers and engineers sometimes needed to interpret missing information or adapt existing components to fit their work.
Our challenge was therefore twofold: expand the library of reusable components and improve the guidance needed to understand and implement them consistently.
Understanding Phoenix and the People Who Use It
We evaluated Phoenix and the workflows of the designers and engineers who rely on it. Through a design-system audit, comparative research, and stakeholder interviews, we examined how component documentation supported design and development, and where missing information created additional work.
This shared research provided the foundation for both component exploration and documentation refinement.
System Audit
Reviewed Phoenix's existing component documentation, specifications, interactions, and guidance to identify gaps in clarity and consistency.
Stakeholder Interviews
Interviewed three Allegion designers and one engineer about their workflows, expectations, and pain points when using Phoenix.
Comparative Research
Studied other design systems and documentation platforms to identify approaches to component standards, guidance, and maintenance.
Where Phoenix Created Friction
Mapping the designer-to-engineer workflow showed how both roles depend on Phoenix at different points in the product development process.
When guidance, component states, or implementation details were unclear, designers sometimes needed to adapt existing patterns while engineers had to interpret missing information or build custom solutions.
Insufficient guidance
Documentation did not always explain behavior, edge cases, or usage decisions in enough detail.
Unclear component states
Missing information increased the need for designers and engineers to interpret or adapt existing components.
Limited reusability
Reusable components needed clearer specifications and documentation to support consistent implementation.
From Product Patterns to Reusable Components
Following our shared research and discussions with Allegion, Team A explored three component directions for Phoenix: Lock Status, Map Pin, and Destructive State.
The work addressed different interaction challenges, from communicating multiple lock states and representing them on maps to establishing a reusable destructive-action flow. Team A developed and evaluated these designs, while Team B worked on the documentation needed to explain and support their consistent use.
Making Multi-Lock Status Easier to Understand
The lock explorations compared ways to represent lock quantity and status, including status dots, the original design, and an adaptive pill.
Extending Lock Status Into the Map
The map-pin exploration preserved the recognizable pin form while adapting status information for smaller map interfaces.
Defining a Reusable Destructive-Action Flow
Team A developed a deletion flow addressing action selection, confirmation, and feedback after completion.
Making Components Easier to Understand and Reuse
As part of Team B, I worked on refining how Phoenix documents reusable components for designers and engineers.
Our research showed that the existing documentation did not always provide enough clarity around component hierarchy, technical specifications, interaction behavior, and usage scenarios.
We developed clearer documentation for Lock Status, Map Pin, and Destructive State, organizing the content around five areas: Overview, Specs, Interaction, Guidance, and Examples. Rather than creating an entirely new system, our goal was to improve the usefulness and consistency of Phoenix's existing documentation approach.
The Five Documentation Areas
Documentation Structure in Context
Component Documentation Examples
Refining Documentation Through Designer and Engineer Feedback
To evaluate whether the documentation supported its intended users, our team gathered feedback from Allegion designers and engineers.
The evaluation revealed problems that weren't always obvious during documentation development. Users encountered unclear component hierarchy, dense technical specifications, ambiguous interaction demonstrations, and insufficient explanations of state priority.
We refined the documentation in response, improving how information was organized, presented, and demonstrated. The iterations were then used to inform documentation for the remaining components.
Four Evidence-Backed Improvements
The component hierarchy was not always easy to scan or interpret.
The documentation was reorganized to make component information easier to understand.
From Documentation Prototype to Implementation
Our revised interactive Lock Status documentation example received positive feedback from Allegion designers and engineers, who found the interaction and its instructions easier to understand.
After the project, Allegion sponsors confirmed that the revised interaction animation shown in our final presentation had been implemented.
This was a meaningful outcome for our documentation work. It demonstrated that a focused improvement to how component behavior was explained could move beyond our project deliverables and into Allegion's actual design-system work.
A tested documentation interaction moved into practice
The confirmed implementation was the revised interactive Lock Status documentation example—not a company-wide rollout of every project recommendation.
What I Learned About Designing for Reuse
This project changed how I think about design systems. I learned that reusable components need more than a consistent visual appearance. Designers and engineers also need clear specifications, interaction guidance, and realistic examples to understand how components should behave and be implemented.
Working on Team B helped me see documentation as a user experience of its own. Through stakeholder feedback, we discovered problems involving hierarchy, interaction clarity, and state priorities that weren't immediately apparent from the original documentation.
One of the most meaningful outcomes was learning that Allegion implemented our revised interactive lock documentation example. It reinforced the importance of designing documentation for the people who actually rely on it, rather than treating documentation as a final deliverable after component design.
Three Takeaways
Components Need Context
States, behavior, and specifications are essential to making components reusable.
Documentation Is UX
Designers and engineers are users whose needs and feedback should shape the documentation.
Validation Has Layers
Testing the component itself and testing its documentation uncover different problems.
Limitations and Next Steps
The project also surfaced constraints that shaped what we could validate and implement during the semester.
Time Constraints
The project timeline limited the scope of our work to three components.
Restricted Platform Access
Limited access to Allegion's live design-system environment meant we could not independently implement or evaluate every proposed improvement.
Platform Feasibility
We had limited visibility into how feasible broader changes to the documentation platform would be.
Validate the documentation in real handoffs
Although the revised interactive lock documentation was subsequently implemented, further evaluation would be valuable to understand how the documentation performs during real designer-to-engineer handoffs.
Future work could also test whether the documentation approach scales effectively across additional Phoenix components.