Enforce, Enable, & Empower
Understanding the spectrum of control in design systems
Introduction
When describing a design system, I usually default to Donnella Meadows’s definition of a system (which I’m paraphrasing) as interconnected elements that have a shared function or purpose. That’s an oversimplification, but it’s a good starting point. When talking about a design system, we often focus on the elements; the components, specs, docs, tooling, maintainers, consumers, et al. But I’d like to talk a bit about trust and control as a dyadic interconnection that binds these elements together. Systems are dynamic and complex structures that often behave in ways we don’t expect, and design systems are no exception. As design system maintainers, we work to create a cohesive experience across products and platforms, and we constantly wrestle with how to best support teams. How we think about trust and control affects our interactions with those teams. This interconnection usually expresses itself in three ways: enforcement, enablement, and empowerment. I’ll talk about these three, but it’s important to note that you likely have aspects of each.
Enforcement
Enforcement keeps control with maintainers. And while enforcement typically has a negative connotation, it can be positive and highly effective when used well. Barriers between traffic lanes and railings along steep winding roads prevent tragic accidents and are appropriate uses of enforcement mechanisms.
But we usually hear about enforcement in design systems when control is too aggressively applied. Product teams complain (often rightly) that the design system is too rigid and doesn’t account for their product’s needs. The system maintainers are labeled “design police” and accused of stifling creativity. Conversely, maintainers feel the system is far too dynamic and needs to be reined in. As they feel control slipping away, the instinctive reaction is to tighten their grasp. Unchecked, this creates a reinforcing feedback loop where products continue to work outside of the system because “it doesn’t work for them”, and maintainers try to lock it down to maintain control. This heavy-handed approach to enforcement erodes trust, isolates teams, and detracts from the design system’s overall purpose: supporting teams to create a cohesive experience across all products and platforms.
The main problem with this approach is that the locus of control is being held entirely by the design system maintainers. It also creates two additional problems: enforcement is an incredibly expensive approach and it is decreasingly effective. You need a massive amount of time and energy to enforce a design system. And as you lean into enforcement, knowingly or otherwise, your efforts have a diminishing return as teams abandon your system.
If you find your team stuck in this enforcement feedback loop, the best way out is to take steps to deescalate. Remember that enforcement is a method that is best used sparingly. What are the steep cliffs that need guardrails, and what can be better managed with some helpful signs along the road?
Enablement
Enablement shifts control toward consumers. This approach works really well when you want consumers to have a level of choice but not be burdened with the details. To keep with the automotive analogy, civil engineers design and build roads and bridges to enable transportation for the public. There is a level of customization: some roads are built to handle large amounts of traffic and others are created to take advantage of scenic landscapes. But individual drivers don’t choose the specific pathways or materials. This arrangement also ensures they get the freedom of not having to build or maintain the roads themselves.
Enabling teams to move quickly without much initial effort is one of the most frequently stated benefits of a design system. And enablement is often driven by really positive mechanisms. Maintainers have established a good relationship with the teams they support, they have open channels of communication, and they’re highly responsive to resolving issues. New design systems start with a small footprint and must rapidly expand their surface area to be a viable service. In this scenario, enablement is a quick strategy to determine where consumers’ immediate needs are without too much concern for bloat. But as a design system matures, it reaches the limits of that approach.
This is a critical pivot point for a design system, and also where maintainers make significant mistakes. When a team raises an issue, maintainers respond quickly to resolve it. But because they’re now approaching a critical mass, that reflexive action has a larger impact to the system. As this behavior is repeated, maintainers overextend the system to an unsustainable level. The insidious aspect of this enablement trap is that the short term stats look amazing. “This sprint we resolved 30 issues, released 10 variants, and added 16 new icons.” It’s only after the fact that the cost of those choices are discovered: As the system balloons in complexity, maintainers have significantly less capacity to support teams. It can also have the inverse effect for maintainers. As they feel growth of complexity, they become too deliberative and support requests are forwarded to an endless backlog.
That said, enablement is still an effective strategy. But as a system matures, it should be used more judiciously. There will always be bugs to patch, new components to assess, documentation to clarify, and assets to add. Some of those tasks will inevitably be blockers for teams and need to be resolved quickly without much discussion. But having processes in place that allow maintainers more space to deliberate the issue, possible solutions, and the overall impact is critical to building a resilient system.
If you find yourself in an enablement trap, examine your intake processes and your system structure. A healthy level of enablement allows maintainers to provide a quick, synchronous responses* while also allowing for a more deliberative, asynchronous discussion about solutions to happen in the background.
Note: “Responses” are typically different than “solutions.” Responding is about triaging a situation quickly with little-to-no change to the existing system. And that is often enough to get a team unblocked. If the response is suboptimal for consumers or the system overall, that’s when a more deliberative, asynchronous discussion around systematic solutions are appropriate.
Empowerment
Empowerment shifts control further toward consumers, and it can only be sustained in a high-trust relationship. These are the road signs: “Steep grade ahead, use low gear” and “Chains required when lights flashing.” While there may be separate enforcement mechanisms to discourage bad actors, the signs themselves leave full control with drivers. And drivers have to trust that signs are communicating accurate and actionable information.
Empowerment is the hardest trust dynamic to build and sustain for design systems. That is partly because of the nature of trust; it is hard won, easily lost, and requires continuous attention to maintain. But while it is elusive, it is also the most potent. Empowered teams are able to harness the system to evolve their products in a way that is harmonious with other products and meets their specific needs. The design system propels them forward, and they reciprocate by revitalizing and evolving the larger ecosystem.
Balancing support and autonomy is a challenging task, and it’s important to note that an empowering dynamic for one team could feel like abandonment for others. A high-degree of freedom comes with a lot of responsibility, and some consumers may feel that tradeoff is too burdensome. A team’s size, culture, and maturity can all affect how they feel empowered. It’s very helpful for maintainers to understand and empathize with where specific teams fall along that spectrum. It also means that as the system supports more teams, they’ll need to develop layers of support that provide more flexibility for high-trust, autonomous teams and more structure for dependent teams. A good example of this is how some engineering teams we support want to find examples they can grab from documentation and slightly modify for their use case, while other teams want low-level parts to build more custom interfaces for their users. Each approach is empowering for teams, so we support them both.
Empowerment can descend into chaos quickly if it lacks the proper governance. Similar to the road signs, there is nothing stopping teams from ignoring guidelines. This is not a dynamic I would recommend for design system teams that are still settling their governance model. Experienced maintainers may be able to stay ahead of the curve, but inexperienced consumers will often make unfortunate choices. Focus on establishing good processes and trust first and then work up to empowerment as needed.
Conclusion
Enforcement, enablement, and empowerment exist along a spectrum of control. Understanding that spectrum and how those mechanisms affect behavior allows us to more effectively support teams as design systems maintainers. There is no singular best approach, and each has its own place. You need guard rails, roadways, and street signs to have a resilient system. How you decide to balance those mechanisms will depend on maintainers, the design system, and the teams they support. And because systems are dynamic, this evaluation will be a recurring, evolving process.
Thanks for reading!
I wrote this mostly to help solidify my thoughts, but I hope it was helpful for you as well. If you enjoyed this, you might also enjoy following me on Twitter.
