Why you need a dedicated design system team

How the need for a separate design system emerges

Often, the need for a design system evolves holistically. 

We saw this at two separate points during my time at MassMutual. When I first joined the organization, they were relaunching for an upcoming company anniversary. Various teams were rebuilding parts of the site in their own silos, but they were guided by designs from the single design team. What emerged was sort of like a game of telephone - the various components from different development teams rhymed, but they didn't really match.

Teams were on different versions of JS libraries, so we decided to build HTML and CSS templates on top of Bootstrap. Several developers, including myself, worked with design to build out a library of templates, examples and documentation that application teams could then use just like they would with Bootstrap -- include the CSS file, copy the HTML and slowly make the various sections of the site look more cohesive.

Several years in, most teams -- and all new teams -- had moved to React. So, we decided to build a new library of components in React based on React Bootstrap. Teams not on React could still use the CSS and HTML templates; they would just have to do any JS behavior themselves.

At each point, the friction -- with the need to look and behave like the mocks and wireframes from design -- led teams to move away from their own components and adopt the system's components. The benefits of having a single team building components that met most of your needs were easily understood by teams using them and then championed, so more teams adopted the system. Teams only needed to wire up the necessary APIs to pull in content and configure the components.

Benefits of a design system and team

There are several benefits of having a standalone design team manage a design system.

Simplifies communication and feedback

The biggest benefit we found was for the design team. 

Before each version of the design system, there was a lot of frustration because the design team was given a near-impossible task. They were responsible for making the site look cohesive, yet there were dozens of touchpoints for each component -- one for every application that used that particular component. This created significant communication overhead. Worse, when a change was required, each individual point had to be rechecked.

Designers on the design system team worked hand in hand with the developers building the components, creating a single touchpoint. Designers and developers met regularly to review upcoming components and their current designs, allowing for feedback on technical trade-offs or concerns earlier in the cycle, when the cost of change was lower. Finally, when changes were required, they only had to work with one team. The application teams could then simply update their configuration files to use the new version and check the patch notes for any required changes to components -- the severity of which was indicated by semantic versioning.

Encourages systems thinking

A secondary benefit applies to developers. Often, with a junior or mid-level developer, the mindset is to immediately jump into, "How do I solve this?" when presented with a ticket. In other words, they focus on the solution itself. As they progress in their careers, their thinking often shifts to, "Does this solve the problem?" Instead of focusing solely on the task at hand, they'll pause, step back one level and ask, "What is the problem we're really trying to solve?"

Working with a design system can accelerate this skill growth, as there is sometimes friction where a component almost, but not quite, meets a need. Trade-offs are inherent in software development, so the question becomes: "Do the requirements need to change so I can use a system component or is this something we need to build and maintain on our own?" Understanding what problem you're really trying to solve usually influences which path you take. 

In some cases, we would also see those developers open pull requests to add new components or variants to the design system to meet those needs. The resulting discussions provided insight into what is required of a system component versus an application component. Understanding the difference in requirements was often helpful to developers earlier in their careers who hadn't yet made that transition. By working with both a design system and an application team, developers advanced more quickly in their careers.

Enables built-in branding

A company's brand is one of its most important features. Branding extends beyond the logo to color palettes, typography, iconography, link styles and more. One of the challenges with using a third-party library is that you have to adjust all the default settings to match your company's branding, which will naturally change over time. With a design system, that can all be included and have a single point of update. You can also build out libraries of iconography that can be used in future applications, especially in dashboards behind login, which might get less traffic than public-facing pages but are accessed by your most prolific users.

Enables theming for partner sites

Large corporations often have many smaller companies under their umbrella, each with its own branding that is similar but not identical to the main site. With a design system, it's easy to build in theming. By changing a configuration or adding some variables to the code, you gain access to all the same components and behaviors, just with slightly different colors, typography, etc. Having a robust design system enables companies to onboard acquisitions or spin up new partner sites quickly, while ensuring they fit with the overall look and feel of the brand.

Challenges of a design system and team

There are several challenges in maintaining a design system and team. 

Initial adoption

Initial adoption is the first and largest challenge. Once you get that initial momentum, champions will arise that will do most of the work for you. However, to get to that point, you need to get a few teams to see the benefit of rewriting large parts of their application to use the design system components rather than their own.

On the design system team I worked with, one thing we talked about and used in our pitches to these early adopters was an example using Lego. In our library, we offered documentation on the components as well as more complex templates composed of multiple components -- similar to Lego bricks and Lego sets, building models from individual Lego bricks. We would use these templates in our conversations to show that while there was an upfront cost, once they adopted the system, it would do 80% to 90% of the work for future features -- since design would be giving them wireframes made mostly, if not entirely, from pre-existing design system components they'd already helped build. 

Because each component was built to WCAG 2.1 AA standards and was responsive -- i.e., they were agnostic of what device they were served on, adapting fluidly to various screen widths individually as well as the grid they were built in, doing the same. As long as they followed the documentation, the team didn't need to worry about building and testing for that beyond the basics. Also, if they did find an issue, it was a system bug, which would not add to their workload beyond filing a bug report and updating their version when a patch was issued.

Beyond adoption, a few other challenges will arise periodically.

Variance

Having slightly different versions of a component and its option pieces is necessary and important. Cards are a great example. Cards in Bootstrap include a variety of content and slightly change the styles. 

Allowing some variance to increase the component's functionality is important. But include too much and you run into increased cognitive load. Users will see several components that look similar but aren't quite, requiring more time to process the information presented to them and potentially frustrating them -- possibly to the point of leaving the site. 

The other side of that is many components solve similar problems -- toasts and modals or tooltips and popovers, for example. If you add too much variance to a component and it has a sibling that overlaps it, it becomes difficult for those less familiar with the system to determine which one to use, frustrating the application teams using the system.

The constant expansion and contraction of component variants, and sometimes even the retirement of full components that are less ideal versions of existing ones, is natural but requires careful consideration, documentation and communication with application teams.

Promoting to the design system

Use cases sometimes arise where no component in the system meets the need. At that point, a decision must be made: Is this something that needs to be added to the system, or is it a one-off that only the application team needs?

The concept of DRY (don't repeat yourself) is foundational to coding. To meet this challenge, we had a rule where if a component or variant came up naturally in designs for three or more teams, it bubbled up to the design system. We found this was a good way to avoid variance concerns while remaining adaptable to emerging needs. Sometimes, down the road, teams would find additional uses for components initially included in applications as one-offs. Developers on those application teams then got to contribute to the design system, growing their skills as they had to adapt their code to meet the system's requirements rather than just their own application's.

Conclusion

Having an in-house design system rather than a patchwork of unrelated components built on a third-party library will lower development costs, provide a more cohesive site even when parts are built by different teams, and make it easier to use and more appealing to users. It's a natural extension of systems thinking, which has gained in value and popularity largely due to AI tools like Claude Code. Equipping teams with the right tools to solve the problems they face is important, and a design system is one of the most valuable tools available. Establishing an independent team focused on the design system to build and maintain the library is a valuable investment for companies.

Eric Rocha is a professional and freelance front-end web developer with over 15 years of experience. He writes extensively on his own site as well as contributing to Informa TechTarget.