Dott

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

Rider Design system proposal

I made a proposal for further development of design system for the Rider app. The state of things was problematic.

Changes to the UI couldn't be made in one place, every new screen had to be built from scratch, there was no dedicated people for the design system.

Proposal step by step

1. Audit of the current components and patterns of the Design library with the design team
2. Prioritized list components to rework
3. Got a buy-in from the designers
4. Made a detailed plan of what needs to be done: from goals and value of DS to processes to vision for the next 1-2 years.
5. Ran a workshop with engineers about we need in a DS and what's realistic to build. As a result:
• Made a case why we need design system
• Learned out about developer's needs and set the focus for the next quarter
• Came up with a definition of MVP design system
• Made a list of specific todo's to get going, such as:
• set up JIRA epic and stories for each component,
• do research on tooling (is there Sotrybook but for mobile?),
• formulate design and accessibility principles
• do inventory of components in the code,
• start creating tokens, etc.
6. 🥳 Got a buy-in form the CTO, who was up for putting more resources for the design system.

This project was discontinued due to changes in team and priorities.

UI Component library changes

1. As a part of design system rework I've restructured the design library:
• reduced the number of categories for easier search
• ordered categories alphabetically
• made icons into components
• introduced a master component for the complex components with lots of variants
2. Broke down color names into Light and Dark categories and renamed them semantically
• Problem
  One palette for Light and Dark modes, which included neutrals and 4 brand colors. Neutrals named as shades of grey (lightest grey, lighter grey, light grey – what does that even mean?). No clarity when each shade is used.
• Outcome
  Used color tokens and did the matching for Light and Dark themes, one set of neutrals from Neutral-100 to Neutral-900, added semantic names for the themes, so that for example “Lightest grey” became "Element”, "Lighter grey” became "Border”.
3. Introduced the color change to the dark mode palette
• Problem
  Brand colors were too bright on the dark background
• Outcome
  New dark mode colors are more muted, contrasting, and thus accessible
4. Added banner component for messaging in the app: information, error, warning.
5. Rebuilt components with autolayout and Figma properties to make them more optimized, robust and responsive. Input field for the Rider app example below.