.png){kind=spacer}
Utilizing internal iOS and Android tools that I helped calibrate to identify Base and non-Base components, the dashboard displays adoption metrics and serves as a key resource for Design and Engineering Managers to identify screens needing attention and to track progress.
Accessibility issues are also highlighted, advocating for accessibility throughout Uber's apps. Moreover, the dashboard helps our design systems team identify gaps in the design system that may not meet engineers' needs.
Despite Uber's Base Design System's extensive coverage, many engineers and designers do not use it, resulting in inconsistent screens across apps.
Moreover, Design and Engineering Managers often lack accountability for screens, impeding progress toward full design system adoption. There is also a lack of awareness of active accessibility issues on certain screens.
How can we effectively monitor and address both gaps and inconsistent usage of Uber's Base Design System, foster accountability among design and engineering teams to achieve the adoption goal across all apps, and increase accessibility awareness in teams?
Design Managers and Engineering Managers were the primary target audience due to their significant influence on design system usage in both design and development.
View screenshots of screens in production with our internal Base component counter tooling in action (red and green markings), making it more convenient for the design systems team to identify gaps on screens all in one place instead of having to look through the application.
Clicking on the screen should also lead to a full-size screenshot.
The accessibility team wanted to highlight “critical” issues, meaning issues that block assistive tech users from completing certain actions. They also wanted to educate the users about what these mean.
This is the reason for the red tags and the information upon hover. Clicking on the tile will also lead to more information about the issues on that screen.
Switch view of screens and metrics filtered by app (Rider, Driver, Eats), platform (Android/iOS), Design Manager, Engineering Manager, or user experience flow.
By making this information visible to the entire company, DMs and EMs will hopefully be encouraged to take ownership of their screens and be more accountable. They will also see which ones under their ownership need the most attention regarding either accessibility or adoption.
View Base adoption metrics per screen, and dynamic metrics per filter and grouping. See which app is leading the “Base Race” (highest adoption metrics) on the leaderboard.
The intention is to hopefully raise friendly competition between teams and encourage better design system adoption overall.
Managers were keen on tracking changes in design system adoption over time to include this data in their quarterly reports and show progress.
This is the reason for the delta tags and bar charts.
We were using Google Sheets to store a lot of data, so I used Google Apps Script to bring the dashboard to life, allowing any sheet changes to reflect immediately.
This turned out to be very useful, as the accessibility team conducted their audits using Google Sheets, so this could also be linked and used within the site.
Within Google Apps Script, the dashboard was primarily built with HTML, CSS, and JavaScript, with the addition of jQuery, serving as the foundation for its development.
Since the start of 2024, I have been actively involved in redesigning over 100 legacy Rider screens using our Base components, collaborating closely with our engineers to implement these changes.
The Base Adoption Dashboard played a crucial role, serving as the central tool for Designers and Engineers to track these migration efforts. By the end of the second half of the year, we achieved a notable 17% increase in the average Base Adoption rate in Rider, significantly improving user experiences across screens worldwide.
It’s important not to overwhelm the user with a lot of information. I had access to so many different kinds of important data, but I had to keep the user in mind and make sure I was displaying what was relevant to them.
We can’t just penalize managers by only showing low scores, as it discourages their engagement with the dashboard and adoption of the system. By showing progress, we motivate them to contribute and also update their own reports to leadership.
It's a win for the design system team and for them! 🥳
Design systems can't cover all cases. Some designs are too custom and specific for a design system to handle. Although a tedious process, these cases needed to be excluded from the overall score.
As part of the design systems team, I naturally favored using Base. However, designers and engineers have their own deadlines and priorities, often resorting to quick fixes that bypass the design system. Strengthening education about the system and its accessibility is key.
