Maybe we don't want too many design system team veterans
Rotating people on and off a design system team can maintain enthusiasm, engagement, and connection between the design system and the rest of the business.
Design systems should exist, where possible, independent of the delivery roadmap of any particular product, or business unit. If a design system is beholden to a specific product, it can’t serve the broader business’ needs in an effective, independent, way. The problem with this? It’s also an argument that justifies a design system team existing in an ivory tower.
This ivory tower problem is both literal, and perceptual. I’m a big believer in the importance of a design system, and its team, being seen in a positive light. As a help, rather than a hindrance. People are more likely to use the design system if they like it, and like the people who work on it.
One good way to undermine positive perceptions is for the design system team to feel removed from the day-to-day concerns of product teams. If the product teams feel under pressure of delivery, feature build, release dates, and don’t think there’s empathy from the design system team, then there’s likely foot-dragging on adoption at the very least.
And existing in an ivory tower is a very literal threat to the empathy a design system team needs to deliver good work. A design system exists to be used - it’s otherwise pointless. Embedding it into the natural process of design and development at the delivery level is vital. That means maintaining a real understanding, practically and emotionally, of the business pressures of product teams. It’s vital for the design system to serve its consumers. But it’s equally vital to engage those consumers enough that they grow to become contributors and maintainers, to support the vibrancy of the design system community and ecosystem.
My predecessor as Program Director of the IBM Carbon Design System, Jeoff Wilks, often suggested what I think was one good method to address these concerns. He would say, and I tend to agree, that a design system team should be a primarily transitory positing rather than a permanent resting place. That, bar perhaps a small cadre of longer-tenure specialists, designer and developer practitioners should spend 1-2 years on the design system team, and then they should move on.
The process would have some solid benefits.
It would keep refreshing the design system team with incoming contributors who possessed very recent product work experience. Those new team members would be able to apply that understanding and empathy to solving design system problems.
It would see design system team members “rolling off” onto product teams. There, they would be the design system expert on the team and, hopefully, also the design system evangelist. The adoption, and consistent implementation, of the design system would be driven by these people.
The design system would feel a more connected piece of the overall design and development community. Engagement and enthusiasm go together, and would better integrate the design system into the DNA of “how we release products”.
Organizationally this can be difficult to do. Both Jeoff and I apparently made Carbon too fun a team to work for…nobody ever wanted to move on! And depending on your company’s process and logistics, this “tour of duty” approach can be difficult to put into place. Other alternatives might include even shorter placements and staff swaps (e.g. a designer or developer swap between the design system and a product team for the span of a quarter).
Design systems can risk getting too far removed from the people they’re actually there to help. There are many ways to address this in terms of organizational change, process, culture. All of those things are, to some extent, a by product of the fact that companies are made up of people. So one way to achieve positive disruption, with real and enthusiastic buy in, can be by moving the people themselves around.