Dashing, a design system to build tools serving 300+ markets and 10 million riders

Design system and accessibility

Summary

Problem

Dott's operations web tool had a lot of legacy design and inconsistent code, where engineers had no components to and designs were partially outdated and full of inconsistencies. This wasn't just about aesthetics—it was slowing down our product development and making it hard to maintain quality across our rapidly growing platform.

Solution

I took the initiative to lead the design system effort, starting with operations tooling. Key decisions included:

1. Conducting a full audit of the Portal to identify and list all components.
2. Prioritizing components through a workshop with developers and strategically focusing on high-impact ones like forms and tables.
3. Implementing a token-based approach for colors, spacing, and typography.

The main challenge was getting engineering on board, but thanks to a supportive engineering manager and creative developers, we made incredible progress. 🚀

Here’s a before and after for a typical table:

Active passes – before

Active passes – after

Outcome

The outcome was game-changing: we got a robust component library, standardized our UI patterns, and made development much faster. Using the words of one of developers on the team:

As a developer, I also love working with design systems, which brings two main benefits:

1. Design system tokens and components eventually become reusable in the app code, which makes working on the UI faster, since some things are already pre-made or can be built from predefined blocks.
2. When a developer has to come up with the UI themselves (e.g. there is an urgent feature to implement and no design capacity), it is much easier to rely on an existing system. The result may not be perfect, but it will look consistent and will likely use UI elements already familiar to the users of the app.

Beyond just the components, we built a proper foundation for design system with tokens, documentation, and clear guidelines. The best part? It was truly a team effort, showing how good collaboration between design and development can transform product development.

Here's the overview of the process

1. Set up the token library.
   • Added color tokens and created light and dark theme in Figma (mostly for the Rider app) to convert the designs to dark mode in 2 clicks instead of recreating all assets.
     
   • Added spacing and typography tokens using Figma variables.
   • Collaborated with the devs to get it implemented.
2. Made a list of all necessary components and added them to Figma.
3. Strategically decided to focus on most impactful ones first: forms and tables.
4. For each component I added a changelog, component section, guidelines and specs, and examples of use when necessary.
5. For each component I add a JIRA story for the engineers to pick up.
6. Because of inconsistencies I had to make a lot of new design decisions and defended them.
7. Got feedback from the design team (who were my stakeholders) and developers.

Case: table components

Tables are tricky to both design and develop. Portal has a lot of tables for all sorts of information from battery settings to employees data.

In order to get a good overview of ALL the tables in the product I went on and made screenshot of all of them. Then I could categorize type of cells and see the structure of the table.

Previously, the table components in Figma were built based on table rows. Each row had different number of columns/cells and that was the only difference.

Such aproach didn't take the data type into account and hence wasn't very flexible. I decided to make the cell type the key component. I introduced various cell types based on content and added some neat details, such as tabular numbers for easier comparison in a column

Here's a part of the spec that describes types of cells.

Here are some examples of before and after.

Batteries table – before

Batteries table – after

Active passes – before

Active passes – after