About the design system team: Goals, pains, and successes

In this post, I want to share my experience of working in multiple design system teams, and it will not be a technical post, but more about the goals, pains, and successes of it.

Introduction

A design system is a collection of reusable components, guidelines, patterns, and best practices (including accessibility and responsiveness) that help a company to build consistent and efficient user interfaces. It provides the building blocks to create a cohesive user experience across your product or products and platforms. Multiple disciplines are involved: Design, Frontend engineering, Product management, and more.

A design system team is a group of people who cover the disciplines mentioned and who are responsible for the design system.

- Is it always necessary to have a design system?: I think so (at least in most cases), it helps to create consistent user experiences, to speed up the development process, and to make the base maintainable.

- Is it always necessary to have a design system team?: No, depending on the size of your company and the complexity of your product, you can use a third-party design system, or the product team(s) can work on it at the same time as they work on the product. But if you have a complex product or a large team, then it is worth having a dedicated team to ensure that the design system is well-maintained, up-to-date, and aligned with the product’s goals.

Goals of a design system team

The final (and more important) goal is to free up product teams from non-product-related tasks. Letting them focus on building product-related features and solving user problems.

They should not worry about (or solve) common design tokens, components, accessibility, patterns, or workflows. Each second they spend on those tasks is a second they are not spending creating a better product.

We can split that goal into smaller goals:

They can vary depending on the company and product, but some common goals include:

Create the design tokens: Design tokens are the variables that define the design system’s visual style, such as colors, typography, spacing, etc. They should be consistent and reusable.
Create the basic UI components: Those components are the building blocks of the design system, such as buttons, inputs, modals, etc. They should be reusable and customizable to fit different use cases. They are commodity components; every design system has them, but they should be well-designed and well-implemented to ensure a consistent user experience. Even if they are common, simple, and commodity components, there are important decisions to be made regarding consistency. For example, in a button, we can render icons in the left or right side, or just on the left side.
Ensure the components are accessible: Accessibility is a critical aspect of any design system, and the components should be designed and implemented to be accessible to all users, including those with disabilities.
Define the common patterns: For example, how to render the tabular data, the elements can be rendered in a table, etc
Define the workflows: How the user should create a new element, what are the steps to follow, how to handle errors, and how to show errors, etc.

Clients of the design system team

In a product team, the client of the delivery is clear: it is the customer, or the people who use the application.

In a platform team, the clients are the engineering teams.

In a Design System team, the clients are both, the customers (because are the ones that consume and use the components, patterns and workflows) and the product teams (product managers, engineers and designers) as they creates the product based in the components, patterns and workflows the design system team provides.

This is very important because, as a design system team, you need to understand the needs of both the customers and the product teams. You need to create components, patterns, and workflows that are easy to use, flexible, and customizable, but also meet the needs of the customers.

Legacy and consistency

Unless you are creating a new design system before creating the product (something that is not common), you will have to deal with legacy components, patterns, and workflows, not necessarily part of a formal design system, maybe created to cover a specific need at a specific time.

Making the migration to a new design system is not a one-shot task; you can not freeze the product for weeks and months to migrate all the components, patterns, and workflows. You need to do it gradually and cause visual and user experience inconsistencies in the product. There is no magic solution to this; we can minimize the inconsistencies in the time and in quantity, but we can not eliminate them.

Migration strategies

Horizontal migration

One strategy is to work first on the new components (in design and frontend) and replace the ones that have a (more or less) 1
match with the old components. For example, the buttons, inputs, modals, etc. You need to know the real world is not perfect and usally the new components doesn’t match 1
with the old ones, you need to define an strategy to create a catalog of the use cases of the old components and how to migrate them to the new ones (note: not migrate a behavior can be an aceptable solution).

This strategy allows for the completion of some old components, but requires time to create the new components, before replacing them, and you are not getting feedback on the new components until they are used in the entire product, and it creates horizontal inconsistencies (across all the application pages/views).

One advantage of this is that you can use codmods to migrate the old components “automatically” (not completely, because maybe the old component uses runtime calculated properties that are hard to migrate via codmods, but to help with the process).

AI agents can complement the deterministic codmods, and they are also very helpful in this process, as they can assist in understanding the context and making decisions about the migration following your migration prompt.

For the components don’t match 1

with the new ones, for the patterns and workflows, you can do the same: Replace them gradually, but in this case the migraction needs more understanding of the context and the use cases, so you need to work closely with the product teams to understand their needs and how to migrate the components, patterns and workflows, and again you are not getting to much feedback until the migration is done.

Vertical migration

Another strategy is to work with a product team, for a specific page or workflows, and think about how to migrate them together. creating the new component, patterns, and workflow during this process. The output of this process is not a final design system (not all the necessary components, patterns and workflows are created yet), it will be a page that follows completely the new design system (components, patterns and workflows), but you will have a bunch of them, and you can use them in the next page to migrate, a page that will need more components, patterns and workflows… This is a more iterative approach, and allows you to get feedback from the product team and the customers earlier in the process and improve them.

In terms of inconsistencies, this will create vertical inconsistencies, inconsistencies between the pages of the same product.

This approach can be seen as slower than the previous one, because the product teams that are not involved in the page to migrate are still using the legacy design system, but the speed is exponentially increased, as in each migration, you will have more and more components, patterns and workflows to use in the next migration.

This approach also creates an “envy” effect, as other product teams see the benefits of the new design system fully applied and push to migrate their own pages and workflows.

With this approach, you can also use codmods to help with the migration, but instead of migrating all the pages in the application at once, you can create codmods for each page or workflow you migrate.

This is the approach my team used in a previous company I worked for, and it was very successful, as we were able to migrate the design system (and the frontend framework) gradually, getting feedback from the product teams and the customers, and creating a more consistent user experience across the product, with a smaller team, freeing up those developers to work on product features.

Being strict with the components’ usage

In a small company or in a simple product, with a few product teams, a design system team very open can work well, as is easy to validate the components, patterns and workflows usage, and to ensure that the product teams are using the design system correctly (in the expected way: consistent, maintainable, etc).

An “open” design system means that you can let developers use all the components’ properties, being sure they will use them in the expected way, following the design system guidelines.

A simple example based on real-life experience.

A table component, this is a common component in a design system, and the cells usually will display text, numbers, links, badges, etc. In an open design system, you can let the developers use the cell property to pass any kind of content or component, you can define some rules or agreements to ensure only some content type is used, when to use it, and how to use it, for example, you define the images only will be allowed on the first column, and the links only in the last column, etc. But the component allows any content in the cell, so the developers can use it in any way they want, but with a small team and a small product, it is easy to communicate the rules via formations, documentation, etc.

But in a large company, with multiple product teams, and a complex product, this approach can lead to inconsistencies, as even if the rules are well documented, they are competing with a large number of other documents and guidelines, and it is easy to forget or misinterpret them.

In this case we need to be more strict with the components usage, and enforce via code the usage of the components, patterns and workflows, in the table example, we can not let the developers pass any content to the cell property, we need to create a system, that only allow specific content types, and limited configurations.

This strictness (even if is essential), specially when the product teams were using an open design system before, can lead to frustration, and the developers can feel this is an artifical limitation that makes they development slower, but it is necessary to ensure a consistent user experience across the product, and to make the design system maintainable in the long term.

Minimizing the frustration

To minimize the frustration of the product teams:

It is important to communicate clearly the reasons behind the strictness, and to involve them in the process of defining the components, patterns, and workflows, something that works very well with the vertical migration strategy.
to provide clear documentation and examples of how to use the components, patterns, and workflows, with good examples (storybook is a nice tool for this), with clear guidelines and best practices.
be fast to respond to their feedback/questions/requests, if you are not fast in providing an answer to a doubt or implementing a feature, it can lead to finding shortcuts or workarounds that can lead to inconsistencies in the product.

Summary

A design system is a kind of commodity, but it doesn’t mean it is not important:

It means it has no value by itself; it needs to be used by the product teams to create value.
It doesn’t mean you should not put attention or resources on it. Investing in the design system can lead to significant long-term benefits for the entire organization.

A good design system and a good design system team will not make your product better magically, make the development faster and the user experience consistent, but a bad design system will make your product worse, providing an inconsistent and frustrating user experience, and forcing the product teams to spend time solving the issue and building blocks that should be provided by the design system, spending time in non-product-related tasks instead of focusing on building product features and solving user problems.

As a similarity, we can think of electricity: it is a commodity, but it is essential for the functioning of many products and services; if the supply is not good, it will be hard to create good products, or they will not be usable if the supply fails. A design system is like electricity, it is a commodity that provides the foundation for building products and services, and needs to be good to create nice products.