Don't become the design systems police
Create positive perceptions of the design system and its team by showing up as facilitators, not by being the source of extra "compliance" work
It’s a not uncommon story. Your design system is up and running. There’s a component library. There’s design guidance. There are universal patterns. There’s executive mandate to use the design system. And suddenly the design systems team is chasing around trying to review work. Calling out non-compliance, or non-usage, in products that are supposed to be ready to ship. And now everyone hates you.
It’s surprisingly easy for a design system team to become the design system police. Your role is now one where you make extra work for people by telling them that what they did the first time was wrong. It’s thankless. It doesn’t win friends. And it’s also a genuinely dangerous point in terms of how the design system is going to be perceived by the people who need to use it.
As much as possible, try to maintain a separation. The team that builds, “owns”, or maintains the design system should not be the same as the people policing design system compliance.
What is the existing process by which your organization signs off work as ready for release? Does that process cover both design quality and “fit for purpose” build quality? At IBM, business units have some form of design and user experience review (or “DUX reviews”). Design system compliance is a part of that broader evaluation - it counts towards the whole, but isn’t the only factor in a review. That works great. The design system team can provide guidance on how to evaluate compliance. But if a product team has a mediocre review, the design system team can be the helping hand, not the hindrance.
“Hey, it looks like those mean reviewers said you can’t ship yet. Let us come in and give you some tips and advice so you can get all your hard work released!”
Of course, not all organizations have that kind of formalized review process. If yours doesn’t, there are still ways to position the design system as a facilitator. Make it a positive influence rather than seen as an obstacle.
Make the design system team a communicative resource available for early facilitation. As facilitators, that can mean regular design and development officer hours, where teams can bring in-progress work at any point in their cycle. It helps to pre-emptively see and address problems early, and better supports correct design system usage. Being open to queries and requests for advice makes the design system team feel like a partner to a product team. Show trust to those product teams be encouraging them to forge forward with the design system guidance as it exists.
But…don’t let facilitation turn into doing extensive direct product work. Avoid getting too hands on in building any team’s product. It’s not scalable, whether that be building a new component they need on the timeline they want, or directly designing and developing their application for them. Empower and enable teams, don’t do the work for them. They won’t learn to love the design system, and they’ll always ask for your time and effort again, once you create the expectation.
So much of design system success is the ability of the design system and the team that supports it to create a positive, realistic, perception. Nothing kills enthusiasm for a design system faster than the perception that it creates additional work, that it’s another hoop to jump through, that it’s an obstacle to a team’s roadmap.
A design system’s position within any organization is not merely one of logistical considerations; does it sit in Design, or Engineering, or somewhere else. It’s vital that it also finds a solid foundation (and subsequently can influence) the culture of an organization, too. Design systems mean, or at least imply, a change in how things are going to be done. Many people’s natural response to change is reticence. Take every opportunity to mitigate that reticence, and avoid the risks of reinforcing it.