Bias in Design Systems
I don’t like garlic. It’s not a dislike for the taste in the moment, so much as an extreme dislike for the way it stays with you—sometimes for days—after a particularly garlicky meal.
Interestingly enough, both of my brothers love garlic. They roast it by itself and keep it at the ready so they can have a very strong garlic profile in their cooking. When I prepare a dish, I don’t even see garlic on the ingredient list. I’ve cut it out of my life so completely that my brain genuinely skips over it in recipes. While my brothers are looking for ways to sneak garlic into everything they make, I’m subconsciously avoiding it altogether.
I’m telling you this, because it’s a great way to illustrate the impact of bias.
Regardless of intent, all bias is impactful.
I have a bias against garlic. If you send me a recipe to prepare, I’ll do it beautifully and leave out the garlic without a single thought because of that bias. My brothers have a bias toward garlic. It doesn’t matter what recipe I share with them, they’ll find a way to include it or double it!
When one recipe is prepared by a garlic-lover, there will be more garlic in the final product. When that same recipe is prepared by me, it will be missing completely. I believe the same thing happens in our work on design systems.
Origin
A few years back, when I was digging intensely into how design systems mature, I stumbled on the concept of a design system origin story. There are two extreme origin stories and an infinite number of possibilities between. On one hand you have the grassroots system, where individuals working on digital products are simply trying to solve their own daily problems. They’re frustrated with having to go cut and paste elements from past designs or with recreating the same layouts over and over, so they start to work more systematically. On the other hand, you have the top down system, where leadership is directing teams to take a more systematic approach, often forming a small partially dedicated core team to tackle some centralized assets and guidelines for all to follow. The influences in those early days bias a design system in interesting and impactful ways.
Grassroots
In grassroots design systems it’s common for a designer to start a design system in Figma. They often make great progress very quickly, and the assets they create are wildly valuable for other designers. But when the process requires a handoff to engineering, things fall apart. Because the system is biased toward designers, devs don’t feel like it’s meant for them. Honestly, it’s not.
Or, perhaps an engineer starts to create their own component library because they, too, are frustrated in building the same things over and over. As this library grows, other engineers become interested, and something valuable is created. Of course, without intentional cross-discipline collaboration, the likelihood that this component library is aligned with the designs being passed to the devs is next to none. This system, living in code, is not something designers can use. Because it’s biased toward developers, designers don’t feel like it’s meant for them. Honestly, it’s not.
Top Down
When leaders push for a design system, there’s often a specific benefit they’re after. The most common reason I’ve seen is that they want to be able to get to market faster with new ideas. They want their teams to work more efficiently—to get more done with less. This bias toward speed makes it hard for a system with this origin story to live up to the quality that’s needed for a foundational piece of product infrastructure. Because the approach is biased toward speed, practitioners concerned about quality might not feel like it’s meant for them.
Episode 048 of The Question
In episode 048 of The Question, Carlos Bàez and I asked the design system community this question:
Do you feel there is some kind of discipline bias baked into your design system assets, documentation, or processes?
What we learned from the community was pretty cut and dried.
Over 75% of respondents reported that they do feel their is some kind of discipline bias baked into their design system assets, documentation, or processes.
A few folks who responded shared how they knew this—one respondent shared:
“In a recent sentiment survey we sent to our product teams, we got feedback that the documentation site is biased toward engineers. I’m not sure how to fix it, to be honest.”
Others hadn’t even considered the idea of bias in their design systems, like this respondent:
“It never crossed my mind that this is a risk, so we’ve not taken any intentional steps to avoid it.”
Types of Bias in Design Systems
The way we phrased the question here was specifically about discipline bias. Since this episode, I’ve done quite a bit more thinking about this and I’ve identified a few other kinds of bias that are common in systems.
Discipline Bias
Discipline bias occurs when your design system offers more assets, documentation, or processes for some disciplines that for others. For example, your design system might offer components for designers (perhaps in a tool like Figma), but not for developers (in code).
This happens a lot in design systems that start with that grassroots approach, as I mentioned above. Often that scenario means individuals are just working on the system as they have time. They are usually focused on solving their own problems, so whatever happens to be their primary discipline is where the majority of the effort is focused. Hence, bias.
Why does discipline bias occur?
Most design system teams prioritize the UI design and frontend engineering disciplines in their system offerings. While many other disciplines are needed in the product development process, we tend to value designer and developers more than UX, content, or QA folks. And, the majority of public-facing documentation sites emphasize assets for these two roles over anything else. As a design system community, we elevate these roles over others.
Product Bias
Product bias occurs when your design system prioritizes the needs of one product over the needs of another. For example, you might choose the features for the design system team’s next sprint based on the needs of a specific product.
Sometimes this happens because that product is sponsoring the work. Sometimes, it’s just how the culture of your organization operates. At one point, we were working with a very large retailer that had multiple brands. One of those brands generated an outsized proportion of the organization’s revenue. In that culture, the most profitable brand got to call some shots and the others had to fall in line. This is more common that we like to admit.
Why does product bias occur?
Many design system teams prioritize the needs of more influential products. They do this to drive adoption or to connect the design system work more directly to revenue.
Having the most influential products adopt your design system means it is more likely that the less influential products will as well. We sometimes see this as a shortcut to growing adoption. And, these more influential products often have larger teams supporting them. So, getting one of them to adopt means getting more individuals to use the system.
If you’ve been doing design system work for very long, you know organizations that are looking for ways to cut costs will often look at reducing the size of a design system team as a way to save money. Teams that are actively supporting the products generating revenue will be more difficult to cut. Sometimes, it’s really smart to intentionally support certain products over others. That connection to the money can get you a bit more stability in difficult seasons.
Tooling/Platform Bias
Tooling/Platform bias occurs when you maintain assets, documentation, or processes for some platforms or tools, but not others. For example, your system might offer assets for designers using Figma, but not for designers using penpot.
I see this more commonly in organizations that grow by acquiring other companies. It’s unlikely that the companies your organization buys are going to use exactly the same set of tools or platforms to build their products, so this acquisition growth strategy leaves organizations with a wide variety of tools and platforms in use across their products.
Why does tooling/platform bias occur?
Many of these teams choose to support only the most common tools or platforms with the offerings of their design system. This is largely to avoid the extensive maintenance that comes with managing assets for a variety of platforms. A simple revision to a component can go from taking a few hours to a few weeks when you have many platforms or tools to keep in sync.
And, many design system teams are being asked to do more with less. This is, unfortunately, the reality of our industry at this moment in time.
The Impact of Bias
We’ve established that there are a few types of bias that are either intentionally or unintentionally embedded into our design systems. Acknowledging this is a great first step. But, what’s the impact of this? Does it matter?
I believe there are a few impacts design system biases, but there’s one that stands out. The bias in your design system makes some individuals feel the system is meant for them and others feel it’s not. This is a problem because, a design system cannot live up to it’s expected value until it is broadly in use. If individuals feel your design system is not for them, the won’t use it. And, as you know, it doesn’t matter how good your design system is if nobody is using it.
Preventing Bias
So, the real question is…how do we prevent bias?
I’ve found a few antidotes to design system bias. Let me share them with you here!
Preventing Tooling/Framework Bias
One antidote to tooling/framework bias is the use of design tokens, which can be transformed into many formats to work with many tools and frameworks. Codifying your design decisions in the form of tokens is a way to broadly support almost any tool or framework with those core design decisions in a format that can be easily consumed and used. This is powerful. It means that, even if you can’t make components for teams using Angular, you can certainly transform design tokens for use in Angular. This way, those teams can get some of the benefit of your work very quickly.
Another antidote to tooling/framework bias is the use of web components with a tool like Stencil. This allows you to build components once and then generate standards compliant web components with framework-specific wrappers so that those components can be used in frameworks like React, Angular, Ember, Vue, and even vanilla JavaScript. Again, this is powerful. And it doesn’t require a lot of extra work on the part of the design system team.
Preventing Product Bias
One antidote to product bias is to encourage micro-adoption among teams who’s products you don’t directly support with a set of components. It’s the idea that adoption means more than your product teams using the more composed parts of your system. Perhaps using your tokens and not your components is also a form of adoption. Perhaps using just your layout core systems is way to start. Or maybe just following your guidelines. All of these are small steps that can lead to much more robust adoption. It’s not all or nothing, and micro-adoption just accepts that reality and lets you define a roadmap for teams to adopt that starts small and grows as they see the value (or as you begin to provide directly relevant components for their suite of products).
Preventing Discipline Bias
I haven’t found a tool to help with this one, but the one antidote to discipline bias I’ve had work is to involve many disciplines throughout the process. Each discipline involved in delivering products in your organization has the possibility to benefit from your design system. However, for that to happen, you need to talk to each of those groups. You have to put yourself in their shoes to understand their needs and perspectives. This kind of engagement builds empathy, trust, and the understanding you need to create assets and documentation for a wide array of disciplines.
A New Mindset
I’ve been reading a book called “The Conduct of Inquiry” by Abraham Kaplan. It’s one of the first texts written about the philosophy of social science.
“Give a small boy a hammer, and he will find that everything he encounters needs pounding. It comes as no particular surprise to discover that a scientist formulates problems in a way which requires for their solution just those techniques in which she herself is especially skilled.”
Perhaps you’ve heard a more colloquial version of this?
“When you’re holding a hammer, everything looks like a nail.”
The more formal cognitive bias that emerges because of this is called Einstellung Effect. This is when we approach a problem with a mindset that has worked for us in the past, even if a better solution exists.
I think this is especially relevant for us in our work on design systems. Most of us came to design systems after having first worked on other digital products. But design systems are programs, not products. The processes we use in the product world tend to be more linear than we want to admit. Those linear processes create all kinds of challenges for us in the design system space, one of which is that they embed discipline bias into our work.
Bias-Creating Mindsets
Let’s look at two extreme but common examples of linear processes I see in the history of so many design systems. The first is a development-driven approach and the second is a design-driven approach.
Linear, Development-Driven Approach
A linear, development-driven approach often begins with the development of design systems foundations and components in a framework like React, then documentation with a tool like Storybook, then design assets in a tool like Figma.
As it sounds, this happens when a design system originates as an engineering initiative. It often begins with developers building foundations and components in a framework like React. As this grows, they want others to see and use their work, so they may integrate with a tool like Storybook and generate some documentation. Now they have the beginnings of what looks like a design system! As awareness for this continues to expand, designers may want to be able to design to align with the assets the engineers are using and so they work to create parity with a set of assets created in a tool like Figma.
While this isn’t a process I’d recommend, I have seen this work for some products—especially in organizations that didn’t start out with a strong design culture. But in the world of design systems, we’re embedding discipline bias into a program that should feel like it’s meant for more folks. Because of the linear nature of a process like this, the decision made in that first step are carried through to each later step. The result is a system that feels like it’s by and for developers, because that’s what it is!
Linear, Design-Driven Approach
A linear, design-driven approach often begins with the design of design systems foundations and components in a tool like Figma, followed by documentation with a tool like zeroheight, and then development assets can be created for frameworks like React, SwiftUI, or Vue.
This is often the situation that happens when a design system begins in the design org. These teams are excited to use the latest features in design tooling that, until very recently, hasn’t truly allowed them to take a more systematic approach. Armed with these new features, their first instinct is to jump into defining color pallets and buttons. From there, tools like zeroheight and knapsack offer Figma integrations making it easy to output a beautiful documentation site. With all of this working, engineering teams can create development assets for any framework they’d like.
Similar to the development-driven approach, this isn’t a process I’d recommend, yet so many product teams work this way (design -> spec -> code). All the bias baked into the design phase of this process is simply carried forward.
Circular, Documentation-Driven Approach
A circular, documentation-driven approach begins by creating alignment with the collaborative documentation of design systems foundations and components, then assets for any tool or framework for use by any discipline can be created.
Instead of these linear approaches, I’d recommend teams start with some alignment. Finding some common ground between all the disciplines involved in product work can be a powerful way to begin. The result of those alignment working sessions can be documentation of the language various disciplines agree to use. While this isn’t all the documentation you’ll need, it’s enough to get teams moving in the same direction.
I think of this as a “bias-busting” mindset because it forces conversations that build empathy. In one sense, the moment when documentation is most valuable to a design system team is while it’s being written. From there, the value decreases over time unless there is tremendous intention to keep it in sync with reality.
Your design system is an idea
The thing I love most about this approach is that it helps to define the mindset shift we need to make as design system practitioners. That shift is one away from “Figma as a design system” or “React as a design system”. Your design system needs to exist absent every asset your consuming teams may need. Your design system is an idea. Every asset you build will require compromise of some kind. Your components in Figma, your patterns in React—they are all less than the pure idea in some way. You have to think of your design system as a concept that is made tangible through the assets and tooling your org needs at a given moment in time. But those tools and frameworks come and go. Your design system needs to remain.
Taking time to align on the idea of your design system means you have something that lasts beyond the fickle tools and platforms we love. I know it’s really fun to make stuff in design tools or development frameworks. I know it’s not nearly as fun to write documentation. But starting with common ground and allowing for the learnings that happen while teams are implementing is a much more unbiased approach. This is the first step toward a more sustainable design system program.
Additional resources
- Documentation Driven Design (by Dave House)
- Documentation Driven Development (by Zach Supalla)
- Documentation Driven Development—The Only Way to Code (by Theodore Negusu)
- Lessons Learned in a Year of Docs-Driven Development (by Jessica Parsons)
Writing Design Systems The Question Featured
Join Redwoods, a design system community.
Sign up for The Question, a weekly design system deep dive.
Explore more of my writing and speaking.
Or, inquire about design system coaching