Design systems and design operations

You've built a world-class design system using the latest tools and created a theme-driven styling solution for your products. What do you do with it now? We think of design systems as tools designers use when creating product or brand assets and prototypes, but it's also a styling solution for constructing those assets. So it's as much an engineer's tool as a designer's, making the next step a matter of adoption. The value of a design system is its presence in all of the company's products, and the task of getting it there is just as important as having it. Adoption is vital, as is advocacy, education, maintenance, and support. Creating a design operations team is the best way to promote your design system and help those using it.

Design operations teams are enabling teams. In the book "Team Topologies," authors Matthew Skelton and Manuel Pais describe enabling teams as groups of specialists in one particular domain that cut across stream-aligned teams, supporting those teams while reserving time for research and study. The enabling team makes informed recommendations on workflow and tooling that other teams can use within their domains.

DevOps is a classic example of an enabling team. They offer advice, support, knowledge, and standards to teams that each own development operations within their domain. DevOps may, for instance, provide uniform patterns of constant integration or security, assist the implementing teams, and periodically audit the work for consistency and quality.

The same principles and patterns of DevOps and other enabling teams also serve design operations. Also, like other enabling teams, DesOps exists to support. Just as a conventional design team may work to create a brand identity, they don't own it, marketing does, and just as a conventional design team may work to create an excellent and consistent user experience, they don't own it, product or engineering does. Design supports the departments and teams who use or implement the output.

In modern companies organized for agility, the service bureau model becomes a cost center and an obstacle. We mitigate the adverse effects by "embedding" designers on engineering teams. However, embedding is not integrating; those designers are not part of the development teams, yet they should be. Whatever their relationship to the team, it works when each design is specific to the development team's needs.

Design systems change everything. They alleviate the burden of from-scratch designs and allow designers, through the principles of Atomic Design, to create experiences from consistent, tested patterns and components. Of course, creativity lies in the assembly, but embedded designers are still pushing towards the development team, where the development team should be pulling from the designers. Abstracting Atomic Design into the design system enables the development team.

Adoption of the design system then becomes one of top-down advocacy. In a Team Topologies world, grass-roots initiatives are often fruitless. The natural impulse is more of the same, so instead of embedding designers, you now embed designers and design engineers on your development teams. Advocate for the system, and convince developers that it's good. Unfortunately, it abdicates the duties of an enabling team and poisons the development team by violating their established communication channels.

Instead of barging into a stream-aligned team's domain and demanding change, start at the top. Advocate for management support and validation. Don't stop until you get high-level recognition of DesOps as an engineering peer, an enabling team with all the responsibilities and trust afforded to other enabling groups. Those embedded designers should be members of the development team, and your DesOps should include at least a design manager, a design systems designer, and a design systems engineer.

Establish your DesOps communication channels. For example, have a dedicated Slack channel, host regular office hours, facilitate workshops, and write lots of documentation, all while researching new patterns, validating what you think you know, and growing your expertise. In addition, expect designers and engineers on stream-aligned teams to avail themselves of your knowledge and check on them from time to time.

Work with management to ensure they know your activities and align your work with their system architecture and priorities. Insist that they, the company and department executives, communicate the necessity of using the organization process and following the recommendations of the enabling teams within their domains. Even though fostering interest via a grass-roots campaign may be possible, results will only be temporary.

Wait a minute. What happens if you don't get management support, or your company organization can't facilitate DesOps? In the case of the former, it's a reality many face. Not everyone embraces change, and management may have different ideas on improving the product and the user experience. It's easy to say keep at it, but the truth is more complicated. Listen to them. As an enabling team, you are duty-bound to facilitate the company's and product's direction. It may be time to refactor your design system or support structure, or it may be time to write. Write those case studies, write those RFCs, and keep hosting workshops and brown bags until feedback becomes constructive, then listen and follow it.

In the case of the latter, learn and study the company organization and fit yourself into it. Team Topologies is a great way to enable agility and evolution of teams and products, but not the only way. So carve out that niche, and move the product forward. Regardless of the situation, don't listen to the siren song of hearts and minds. Convincing developers and designers engaged in creating the product that your way is good is only temporary. They will, and should, follow the company's direction, and so should you.

Creating a design system is hard, making it useful is harder, and keeping it relevant over time may seem impossible. Yet we must still shift our thinking in how we organize, structure our workflow, and communicate across teams to succeed. If your design system is to succeed, design operations become an essential part of the future.