How to Standardize and Fix a Broken Indentation System in a Design System

From conversations with operational product designers, it became clear that all the components of our design system are too large for internal tools. Many of these tools contain full-screen data tables and charts. In these information-rich contexts, it is important that as much content is visible on the screen so that users can easily scan, analyze and compare the information. Unfortunately, when operating product teams tried to adapt existing components to these contexts, they looked gigantic and out of place.

At first glance, it seemed that we needed to significantly reduce the components in order for them to work well for operational products – but how small can we make them while keeping WCAG AA standards?

Examining indentation

Availability is the generally accepted Lyft quality standard and therefore is not negotiable in our design system. Previously, our in-house products were mostly not tested against this standard because there weren t many centralized resources or guidelines that they could follow. No wonder that when we raised minimum target pointer size up to 44px in initial meetings with operations teams, this became a stumbling block and a likely problem.

Instead of continuing to insist on this, we conducted additional research. We looked at how other companies have solved similar problems. The following articles in particular have clarified the issue very well:

In the meantime, we checked existing web components internally to see if the current approach to resizing and padding could be extended to our products.

We learned that although we had Default and Compact sizes for most of the components, these names did not always correspond to the vertical height of the components, the size of the content (that is, the sizes of text and icons), the horizontal and vertical padding, or the shape of the components. … (i.e. border radius). Some components were missing two sizes, while others had different version names “Default” and “Compact”. The component kits grew fragmentarily – a side effect of oversight in our process.

When we add new components to libraries, we test their use across different products to standardize their sizes. We don t often rate all of the components as a set, so over time the “Default” and “Compact” sizes have come to mean slightly different things in different contexts.

Before exploration, we assumedthat the crux of the problem is that operating products require smaller components, but those components must be inherently inaccessible for pointer purposes. However, during the audit, we realized that we had never approached size, spacing, and density in a holistic manner before. What do we really what is needed is clear and consistent rules on how to apply density in both consumer and operational products.

Determination of density

Density is an overloaded term and usually refers to screen density or the literal resolution of displays in pixels. While in-house product teams have always asked for denser components for denser interfaces, they weren t talking about pixels and screen resolution. In our research, we found that there are 3 dimensions that make the screen more or less compact. These dimensions include visual density, or a set of spatial relationships within and between visuals on screen, including:

• Content size (e.g. font scale, icon scale)
• Padding and shape of the container – the space inside the container
• Layout – the space between screen elements

It seemed that as soon as we determined the density, everything else began to fall into place. First, our “Default” and “Compact” sizes can now also be defined and standardized. We set the default values ​​for padding, content scales, spacing, and container shapes to a base 8 pixel grid. We ve also standardized the typography styles we use in operational products (a separate article on these coming soon)! These decisions had a happy side effect, greatly simplifying the decision-making process to add new components to the library.

Roughly speaking, consumer web products can use “Default” components, while working web products can use “Compact” components. But we ve also highlighted certain exceptions and provided more detailed instructions on how to mix different densities on the same screen on our documentation site.

Finally, we realized that the third density dimension (layout) was the key to creating an accessible, visually dense interface. With our minimum requirements for content size and visual height (at least 6 pixels between each UI element), we can ensure that the pointer target is accessible even for the most overloaded layouts. We simply define the interactive area of ​​each component to extend slightly outside of its visual area and check that the interactive areas meet our layout requirements. To keep things simple, we ve created Accessibility Helpers in Figma to visually show designers the minimum target pointer area available for each interactive UI element.

5 easy steps to fix system indents

Our path to spatial clarity has been a tortuous one: Correcting padding in an existing mature design system is not easy. For example, we learned about the importance of publishing sizing changes all at once in a batch, rather than individually, when system users began to notice that some components were resized and did not correspond to components that we had not yet “fixed” (oops)! We ve also learned that only design system enthusiasts are really excited about the attribute updates, although everyone loves the shiny new components.

If you re trying to adapt your system to handle a new visual density, or if your system suffers from inconsistent sizes and spacing like ours, we hope this plan will help you:

1. Audit the components of your system, decide how many different visibility options you need, and name them.
2. For each density variation, define values ​​for content size, padding and container shape, and layout spacing in terms of your base pixel grid (bonus: involve system users in decision making)!
3. Apply standardized names and visual density values ​​to all existing components (this is a basic task that can take months and a reliable communication strategy to complete, but worth it).
4. Create new components so that each component has a version for all visual density variations.
5. Publish bulk visual density changes to your libraries to validate the fact that it is a holistic change at the attribute level.

As messy as your audit table is, know that accessible, information-rich interfaces are possible!