Good systems make good culture
As design systems grow, the teams creating and maintaining them mature to shape policies like governance, themeing and contribution. The rationale contained in these policies drives major impact on an organization’s culture. We need a balance of expert creators and iterative service designers to be effective as design system owners.
First, consider the pedal board 🎸
Systems exist all around us. A whole slew of folks have defined design systems in much more eloquent ways than I can, so instead of a definition, let’s check out at an example…
Look at a pedal board for an electric guitar, and you’ll find a collection of components. Each component, or pedal, blends the science of sound with the art of music to tap into emotion and unique vibes.
But it’s not about each individual component. In systems, each part relates to all others under a common set of rules. Each pedal was crafted to work together with other pedals in beautiful, sometimes unexpected, ways. They can stand alone or be layered. They can be arranged in a personalized way for the musician. And they can be customized with stickers.
But it’s not about the fine-tuned-over-the-years pedal board either. It’s about how it all comes together to create music. To create an experience at a live concert. To create emotion and art. It’s about the experience it creates for the listener (the user) singing along in the car or losing their voice at a concert.
A good system combines art and science to create magic ✨
Make the pedals
But how do we get to a system that creates magic? The first stage of a design system team is to create solid tools. This can include everything from tokens to page templates. To hone in on what’s most valuable to consumers of the system, the design system team needs to spend time understanding their primary users; designers and developers who will be applying the system to create end-user (customer) experiences.
Depending on the size of the consuming team and the types of products being created, the system might look like a basic pattern library in Figma, or it might become a system of decisions and complex components with complete parity in design and code. All across this spectrum of simple to complex, the design system documents decisions so they can be reused and not re-decided in an endless loop. If you don’t document these decisions, the questions will get repeated endlessly or the answers will be ignored and replaced with chaos.
To create the right kind of system for your consumers, first work to deeply understand the pedals they need to do their job. Don’t seek to mirror snazzy open-source systems like Carbon or Material. Most likely, that’s not what your community needs. Don’t decide for your community. Ask, learn, and validate every decision about what will be delivered and in what order. After all, the design system exists to set teams up to create solid experiences at higher levels of quality. We seek to understand our community so that they can spend more time seeking to understand our customer.
Beyond the board
The pedals are crucial. Without them, what’s the point of a board? With the pedals in place and teams working to create their own boards, you might notice some unexpected influences. The decisions and logic that ground a design system impact an organization’s culture for better or worse. Usually, for worse if the impact and logic are not proactively designed.
Let’s look at three policies that are crucial to a design system’s health and longevity and the potential benefit and harm that can grow from them. For each policy, we’ll look at either end of the spectrum and a blended approach (spoiler alert, the blended approach is what my team does or seeks to do at U.S. Bank). I’ll share my definition of each policy as well, just so we’re all on the same page. You might have a different word — probably a cooler one.
Governance
Def: How teams make decisions. This can include what belongs in the design system, when to create something custom, and how we identify the best things to reuse. Governance most directly impacts how a team thinks about reuse and creating custom components or experiences.
One approach to governance is to lock things down with a strong focus on consistency. Reduce the creation of custom things outside of the design system as much as possible, and closely control what gets shared and reused across teams. This can have some tangible benefits for teams and customers. If your products are suffering from obvious inconsistency today, this might be the best approach. But if the design system team becomes the consistency police, it can hinder collaboration and put a serious damper on creative exploration and ideation. It reeks of bureaucracy and design by committee, and it often sets the design system team up as the bad-guys or as approvers.
The opposite approach is to open things up. Let teams across an organization add to the system directly or swap components through informal process. Let them seek exceptions to the defined best practices. Let them tinker, ship unicorns, and potentially make some breakthroughs. This approach can create an eclectic, creative culture. It can also create frustration for the folks who are left to recreate the wheel or navigate ambiguity when they’re not seeking it. In a hands-off-parenting model of governance, the small questions like the right type styles and how much spacing between text inputs can cause hours of debate and rework.
Let’s look at a blended approach. The core design system can stay rigid with very limited edit rights, possibly even only the design system team. There could be an open, collaborative space where teams can share components they’ve created at various levels of completeness. Teams could also have a defined point in the design process to throw the system out and explore freely (think innovation sprints or co-creation sessions). Execution should be simple, and innovation should be empowered by having the time and brain-space dedicated to asking questions. With clear expectations and rules, creativity can thrive in the right direction.
Blended governance defines how to be a good citizen of the team.
Themeing
Def: If your system supports multiple brands (or flavors of the same brand), this is how themes are created, applied and maintained in specific customer segments. If you’re new to the concept, the Carbon design system has some great definitions.
Similar to governance, themeing can be controlled rigidly to seek consistency above all else. With a rigid theme policy, an organization has a single, consistent brand expression regardless of customer journey and profile. If you’re a social media company, the experience feels the same whether the user is a casual consumer scrolling the bottomless feed or a small business owner setting up complex ad campaigns. It all feels the same and in fact looks uniform front to back. There’s simplicity in this approach, but for products with contrasting user types it lacks proper tailoring.
The opposite approach would be to support limitless themes in the system and open up visual fine-tuning to individual teams. Some teams might want 4px rounded corners on their buttons, others dig a fully rounded pill shape. And who cares? All teams are using the design system and shipping experiences faster. Teams are free to create customized experiences tailored to their specific customers to the smallest detail. But the cost is consistency. If a customer crosses segments, will they feel confused? When the small business owner hops over to check their feed after finally launching the campaign, will trust erode slightly because the experiences feel divided? Similar to governance, teams will also be left to navigate each visual detail for themselves and maintain those decisions over time.
One blended approach would be to set up a design system that supports multiple themes flexibly, with strict boundary lines for each theme. Instead of individual teams creating and maintaining their own unique preferences, there are a handful of defined themes that are applied more broadly. Themes might be owned by the design system team, or the larger business units that have a strong business justification for modifying those precious token values. In the social media company example, the team working on the feed might add more breathing room, expressive type and motion. The team working on the small business ad campaign forms might prioritize information density and reduced motion because their user spends hours a day in this experience getting work done. The brand expression is free to match the customer’s emotional state during work and play. It’s grounded in intention and consistency to maintain trust.
Blended themeing creates logical tailoring with a consistent core.
Contribution
Def: How teams share their work with other teams through the design system or similar hubs of reusability. Contribution helps the design system team scale, and more importantly it builds stronger connection between the system and actual customer needs.
Contribution is directly connected to a design system team model (more on that from Mark Boyes-Smith). The rigid contribution policy looks like a centralized team that completely owns, adds to and maintains the design system. This single team or group of teams has total control over what gets published and documented. Other teams are welcome to report bugs, request new features and share their work for consideration, but no one else is really able to touch the machine. The financial cost is greater, but it darn near guarantees progress and a high level of quality and expertise. For a detailed flow diagram, check out what Brad Frost put together in Figjam.
On the other side of the spectrum is a decentralized team model where there is no “design system team” at all. There might be part-time designers and developers creating and publishing, but largely the system is a community resource with varying levels of contribution, quality and regulation. This is the cheapest way to stand up a system, but it often results in lower quality and unpredictable updates. At its worst, this strategy leads to disengagement when timelines get tight and the system can atrophy beyond repair or split into sub-systems owned by different groups.
The blended approach is known as a hybrid team model. There is a central team, but that team relies heavily on the community for contribution, adoption and validation of their work. The central team works to enable design system experts on teams across the organization. They might even have a rotational program so designers and developers can jump in, work on the system and take their new knowledge back to their feature team. Investment is still high, but the design system can grow faster and over time the community can play a bigger part in the maturity of the system.
Blended contribution (or a hybrid team) matures the system faster and also builds key systems thinking skills across an organization.
Conclusion
My focus has obviously been on design systems in large organizations. This concept applies to any system at play in a team, from how we hire to measuring skills to allocating funds for projects. The way systems are designed directly impacts what teammates value and what behaviors get rewarded or remodeled.
All of this shapes an organization’s culture around experimentation, reuse and general arm-linking. We need new thinking and leadership in design system teams to push teams to the highest levels of quality. Many designers are not equipped to ditch the pixels and go deep on process and policy. I know I’m learning and growing every day. We need service design skillsets to design these policies rooted in empathy and tuned-in to where an organization is at and where it needs to go. The service design of these workflows enables teams to measure their impact at new levels.
