Maintaining a design system is a significant task, and how you structure the team that does that work may be helping or hurting your cause.
Whether you are working with a legacy design system or have just started to build it out, something worth considering is how you organize the team that makes the decisions about the system. Often an organization will simply default to the setup that worked for them in the moment when their system was built, even long after they outgrow it.
There are three models we’re going to explore today: decentralized, centralized, and external. Each type of organization structure has its own advantages and disadvantages when it comes to maintaining a design system. The key is to pick the poison that your team can handle, one that plays to its strengths and reflects its existing style of collaboration.
Decentralized: Multiple teams contributing to a design system
Large organizations can not only have multiple departments —say development, design, and business development teams—but a number of product teams each with their own team composition. Each product team may either contribute to their own isolated design system, or an organization-wide design system. This section is speaking to the latter case. This doesn’t necessarily mean every single person from a team contributes to the system. Often, representatives across the organization allocate some of their time to design system work.
This model may be what your organization turned to naturally if different teams don’t typically collaborate with one another or are otherwise in silos. The hope is that by pooling the organization’s efforts, a design system can be created that benefits the organization as a whole.
This model might no longer be working for your organization for several reasons. There might be a greater need for the system to be cohesive system-wide. Stakeholders could find that accessibility compliance is suffering or that the system is having trouble keeping up with the complexity of the product. Without a central team advocating for the system, teams could end up defaulting to custom solutions to each problem instead of turning to the system.
Pros of a decentralized approach
The system is based on the direct needs of the products. Product Team A and Product Team B will both feel like the design system is reflecting their needs because they are empowered to address those needs themselves. Patterns and their constituent components can be customized to the desired level of detail.
Agile iteration and implementation. In a decentralized model, there is no third or outside party acting as a bottleneck for getting the design system out the door and in use by its subscribers. The perception of shared ownership over the system may even smooth over adoption efforts since contributions to the system are immediately driven by product needs.
Cons of a decentralized approach
There is a higher potential for redundancy. The saying about too many cooks exists for a reason. If Team A has a need for a button component with round borders, and Team B has a need for a button component with square borders, the design system is going to end up with two similar but distinct buttons. They may vary slightly but ultimately this work may have been a duplicated effort because they share the same basic functionality.
Consistency throughout the system may suffer. To add on to the previous point, Team A will make different choices in their implementation than Team B will. Team A’s button may have accounted for additional states, or Team B’s has an icon button variant. Which button does Team C use? Their product may now be using both. Furthermore, what is called an “active” state for one button may be considered the “selected” state in the other. Lack of a shared language can make communication a roadblock when teams do collaborate with each other.
Lack of a shared language can make communication a roadblock when teams do collaborate with each other.
Centralized: a dedicated design system team
If an organization has the resources, it may be able to support a central design system team dedicated to all of the system’s responsibilities. Members of this team may have been sourced from existing departments, or not associated with them at all. Whatever the case may be, compared to a decentralized approach, a centralized team will be doing their work with respect to the organization as a whole.
An organization may have turned to the centralized model if the need for consistency and efficiency has arisen, such as would be the case with a parent company that has grown to house several brands. The size of the organization might be the limiter, and turn to a centralized model just from the lack of staff.
How do you know if your team should move away from a centralized model? There might come a time where your organization’s products require more than one team to ensure disparate needs are being addressed. One team may develop blind spots across all the contexts – the multiple platforms, the different apps – that the system will be consumed in.
Pros of a core design system team
No one’s playing favorites. Rather than placing one product’s needs over another, the core team addresses needs from a top-down perspective. They ensure that the team reuses components, minimize repetitive design choices, and implement measures for compliance to the standards. Note that this could result in components that aren’t flexible enough to meet a single team’s requirements, but this is why collaboration becomes tantamount with this model.
A team member’s time is all design system time. Product teams are able to focus only on product goals, and the design system team is able to focus only on the system. This doesn’t just mean defining design tokens and patterns, but the more behind-the-scenes duties that can fall to the wayside with a decentralized model. These include creating the contribution guidelines, solidifying an organization’s design language, or taking on educating the rest of the organization about the design system.
Cons of a core design system team
The design system team could become a bottleneck. It is not uncommon that the needs of the design system will be at odds with what product teams need. If the design system team is implementing a change, product teams may have to ship with an older version of design system components to make it to release on time. Too many speedbumps may hurt the legitimacy of the design system, and push product teams away from adoption.
Too many speedbumps may hurt the legitimacy of the design system, and push product teams away from adoption.
Collaboration becomes even more of a requirement. To make sure that the design system is being built for the sake of the organization and not for the sake of the design system team itself, the core team needs to have context on the needs of product teams and ground-floor visibility on the work being done. This means showing up during design reviews or other collaboration sessions the organization may have.
External: working with contractors
Of course, it may not be realistic to allocate some of your team members’ time to working on the design system. You recognize that there is a need to expand the system, create documentation, or create guidelines around contributing to the system, but you don’t have the hours to spare. An option is to contract that work to an outside team. With the restrictions of tight deadlines or other priorities, many teams may choose to go this route. Otherwise, stakeholders may want a proof of concept that internal teams don’t have time to put together.
This option can take many forms, up to being a supplement to the above two models. Just from Sparkbox’s perspective, we have been hired to augment an existing design system team, we have assisted organizations get their documentation written and their documentation sites spun up, and we have helped create design systems from the ground up.
Aside from budgetary limitations or changed goals, an organization might be ready to move on from external assistance once they feel ready to take over the ownership of the system themselves. In the best case scenario, the contracted team will offboard an organization with maintenance procedures after they have gone, especially if they have created a large portion of the system.
Sparkbox’s strategy often includes collaborating with clients to find a contribution process so that the system can continue to grow, working with internal design teams to establish design file standards, and working with internal development teams to stand up any necessary repos. Throughout the engagement we aim to educate the client on the rationale behind why certain decisions were made, so that the standards can be maintained going forward or if they can be tweaked for the client’s use case.
Pros of hiring outside help
Your internal team is freed up for other initiatives. Without having to split their time between product work and design system work, any given team member is spared from the guilt of not being able to contribute as much to their “core” responsibilities.
You can start to address the accumulated design system debt. The backlog is often a mile long, and as long as the design system is in a usable state, then it may not feel like you are able to prioritize some of the efforts that will improve the system. An external team can handle these difficulties, and with the proper communication channels open, keep the internal team up to date on any changes. As an outside perspective, the external team can also perform audits of the system and conduct surveys of its current subscribers.
Cons of hiring outside help
It may take some time to onboard the external team. You know your system. You know its rules inside and out, like when to use a tag versus when to use a badge. You know all of the quirks, like how the menu list component uses the menu-list tokens and how it’s referred to as the MenuList in the code. I, a stranger, will not know all of this immediately. Thus, external teams will often have to learn all about what’s already there before being able to effectively improve the system. Onboarding will scale directly with how big your system is.
This isn’t a permanent solution. Unless you are planning on absorbing the external team into your organization, they won’t always be a resource. Like onboarding, the extent of the external team’s work directly correlates to what they should make sure your team is prepared for. If they performed an audit of the system, you may only have to mark obsolete components as deprecated on your documentation site.
Unless you are planning on absorbing the external team into your organization, they won’t always be a resource.
Your team, your system
There is no singular model for design system governance that will work for every organization, even at different points in that organization’s lifetime. Reflecting on these different models of design system governance may illuminate some of the issues that you and your team might be having with your system, but ultimately a system is like software in that it’s always growing and evolving. If you have the resources and find you need to change your approach, it may be worth taking the opportunity to do so, especially if the same problems keep persisting.
