Atlas Tools
As Atlas became the current design system for Experian’s web product, teams still carried components, tokens, icons, CSS classes, and assets from older libraries. The challenge was not simply knowing that Legacy and Next needed to be retired. Teams needed to know where those items were still used, what should replace them, and which migrations would create the most value.
Atlas Tools is an internal analytics application built by the Atlas team to make that work visible. It inventories design-system assets across product repositories and shows how Atlas, Next, and Legacy are used within each domain.
The tool turns an otherwise diffuse migration effort into a shared source of evidence. Instead of asking teams to modernize broadly, it gives them a concrete view of the work in front of them and a way to decide where to begin.
Making adoption visible
I designed the Atlas Tools interface as a real application of the system it supports. Building the tool with Atlas components gave the design-systems team a practical way to use, test, and evaluate our own library while creating a product that could help other teams adopt it.
That dogfooding experience largely validated the system’s flexibility: we were able to build the application with the components we already had, rather than needing a separate visual language or a large set of one-off UI. It also surfaced a small number of bugs and opportunities for more compact component variants in dense analytics views, which became tickets for the team to address.
Turning inventory into decisions
Atlas Tools lets teams filter usage by repository, asset type, library, and status. They can see active items, deprecated items that still require migration, and deprecated items with no remaining usage.
A team can focus on heavily used Legacy or Next components to make a high-impact migration, or start with lower-usage items to reduce implementation effort and build momentum. The tool also shows the appropriate Atlas replacement, helping teams migrate accurately rather than treating modernization as a generic cleanup exercise.
This makes migration planning more flexible. Teams can choose the strategy that best fits their roadmap while still contributing to the broader Atlas adoption goal.
Making system knowledge easier to access
Developers can use Atlas Tools to look up a component and see how it is implemented across the product. If someone needs to understand how Atlas Card is used in different contexts, the tool reveals those usages across repositories and provides a path to inspect the related code.
That helps teams make more informed implementation decisions. Rather than relying only on documentation or creating a new pattern from scratch, they can review real examples of how the component is already being used.
For the Atlas team, usage data also makes prioritization more evidence-based. When several components need attention, I can identify the ones with the broadest impact and focus iteration or bug-fixing work accordingly.
Supporting a healthier system
Atlas Tools is part of Atlas adoption, but it also supports long-term system maintenance. It shows which deprecated components remain in use and therefore still need a migration path.
When a deprecated component has no remaining usage, the team can remove it rather than continue carrying unnecessary code and documentation. The result is a clearer path from inventory to action: teams can understand what they use, migrate what matters, reuse Atlas correctly, and prevent deprecated components from sitting in the system indefinitely as dead code and documentation debt.