As a Design Engineer on Uber’s Base Design System team, I redesigned and expanded an internal adoption dashboard to make Base usage, accessibility issues, and screen ownership visible across teams, while helping migrate 100+ Rider screens onto the design system.
Adoption wasn’t only about whether teams reached for the right component. It could break down at several points between design intent and what actually shipped, so I mapped where those gaps lived.
A screen could look like Base without actually using Base underneath.
An early version of the dashboard made Base adoption percentages visible, but a percentage alone didn’t explain where adoption was happening, who owned those experiences, or why improving it mattered.
I redesigned and expanded the dashboard around the people who could influence adoption, bringing production screens, ownership, user flows, progress over time, and eventually accessibility issues into one view.
The dashboard paired every percentage with the production screens behind it, so teams could see what the number was actually made of.
I organized it around what managers could act on: user flow, design and engineering owner, product, and platform. Deltas showed movement over time.
Working with accessibility partners, I brought critical findings in next to adoption, so the cost of staying off shared components was visible in the same view.
The dashboard evolved from a view of adoption percentages into a shared way to understand
Alongside the dashboard, I worked with product designers, Design Managers, and engineers to turn adoption gaps into migrations. Before proposing a change, I tested the existing experience and evaluated whether a Base component could preserve its behavior, functionality, and UX.
I treated migration as a product decision, not just a component replacement.
Each migration still had to support the existing experience. When Base wasn’t enough, I worked with the team to decide whether the system should evolve or a custom solution was still justified.
Each screen belonged to a team with its own priorities, so the right technical solution still needed buy-in. I reviewed migrations with owning designers and managers, redesigned screens myself when needed, and helped move approved changes toward implementation.
With engineering, I prioritized low-adoption screens and clear one-to-one replacements that could raise adoption quickly while moving more experiences onto shared components.
The dashboard and migration work became two parts of the same effort. The dashboard made adoption gaps visible, while migrations gave teams a way to act on them and see that progress reflected over time.
The Base team also used the dashboard in broader organizational conversations, to show where adoption stood, how it was changing, and where teams still had room to improve.
Together, the dashboard and the migration work created a feedback loop between understanding adoption and improving it.
Increase in average Base adoption across Rider, contributed to through the dashboard and migration work.
100+ Rider screens migrated to Base.
The hard calls weren’t which component to use, but whether a change preserved the experience a team already relied on.
I expected the technical complexity to be the hardest part. Progress depended just as much on building alignment with teams I didn’t own.
The dashboard mattered because it led to change, and change stuck because it stayed visible. Each made the other credible.