Driving Design System Adoption with Modular Components
Maximize design system adoption by transitioning from a centralized model to a distributed component system
A live webinar and demo session by Bit’s VP Product Itay Mendelawy.
Key takeaways:
- Most design systems take a centralized, “one-size-fits-all” approach that fails to meet the diverse real-world requirements of every team and product.
- Instead of a monolithic library, go “Ikea”: build and distribute independent components including UI components, themes and tokens, icons, fonts and more.
- Developers can easily find, use, mix and match, and fit these components into their projects — all together or incrementally. Get bottom-up adoption.
- Grow a ‘Component Economy’ by making it easy for developers to build on top of components and share new compositions with the organization.
- Let autonomous teams innovate rapidly while standardizing components and design to ensure standards and consistency.
- Track and govern component adoption, usage, and updates throughout the organization.
Transcript
When we think about design systems, typically those design systems that we build are monolithic. And the monolithic design systems that we see when we work with our partners and customers, as well inside the community, tend to compromise adoption in various ways.
The reason being is that we approach a design system in the same way we approach any other project, as a top-down centralized effort to build or implement this thing that we were given as a product or as a feature. It creates challenges for adoption in several ways.
Because this is a large thing with all of those components building, often there are consumers that already built a lot of the UI components they need. We are talking about other teams in the wider organization that already have live products in production.
For some other teams, maybe they need components that the design system is lacking and maybe that design system is not sufficient enough and not composable enough for them to take the features on the UI they’ve built and adapt to the standards of the design system.
And we also see that often a lot of consumers are afraid to get locked into the design system team’s roadmap. If there are any bugs, or new features, or enhancement requests on different APIs, we tend to see a lot of friction when it comes down to consumers wanting something. Because they have bugs right now or they have a feature request they need for them to move forward, and they are now waiting on some other team’s roadmap.
Moreover, collaboration tends to be horrible because if you have a centralized library, then the collaboration around it becomes like this guarded core, in a way that you have to go through loops and hoops in order to get collaboration going. So, if you want to suggest changes, or introduce new functionalities, or even fix an issue, you face some sort of bureaucracy.
Our approach is that if we’re thinking of a centralized effort as something that may compromise consumption and adoption, then if we try to break it down to independent components, maybe we can also solve this problem.
Because ultimately, a design system comes to resolve many small problems in our UI/UX consistency, tokens, different patterns, grids, sizes, iconography, typography, and so on. And while our intention is to build a single solution to solve it all, maybe if we look at each problem separately and solve each specific rule in an independent way using a specific component, we can essentially have this component system that standardize all of the different design rules and guidelines from the designer to achieve UI consistency.
Moreover, if we focus on those components or those solutions being composable, this means that consumers can focus on composing the rules or the components they need in order to standardize the UI. So, in that regard, we don’t want to couple our color palettes to buttons, or we don’t see the same problem for company logos as the same problem for getting fonts done correctly, right?
Those are completely independent problems. A lot of them are of different scopes, and even within those different scopes, you can break down problems even further. So, instead of having this one monolith, we’re trying to look at the design system as how we can build a component system that allows other builders to compose on top of, and take those rules as standards, as guides for their own implementation.
So what does this look like in real life? I’m gonna show from our example and how we’re building a system of components that drives forward our UI/UX consistency.
Here I have an example of a button that is a component, or base-theme that is a component, another button which we’ll touch later, and even a paragraph that is a component. First of all, we’ll touch the base UI component as an example. The problem of having a single button toward them all is something that is very hard to solve.
We can never know how many use cases or where that button we’re gonna use. So, we want to provide the most basic functionality, almost a headless button that is themeable and customizable, and composable, in order to say ‘this is our base button’. So whenever you want a button take this as the base and compose things on top of it.
For example, you can take your theme which can also be a component. I can have all of my color schemes and fonts and everything in a single place, which then I can adapt in other projects. And this applies different primary colors on different elements. And with that, I can even have more stylized items.
If we thought about the former button as the base input, maybe we have a CTA component, a button that can be primary, that can be secondary, that can be a link that is essentially themed, and accepts the styles from a theme. So, it’s no longer a headless component, this button essentially gets standardized by being composed into a theme.
This way, we decouple several problems. We decouple the base functionality, the accessibility or interactivity of what is a button. We decouple the theme itself, and then we also have a button with a specific set of behavior, like being a secondary button, or a link button, for example. We can even do it, for typography, so y having paragraphs, or headers, and so on. And each of those components can be sorted in different scopes.
So, we can sort our design system and break down which components deal, with our base UI implementation, all of our basic building blocks. Second, write button icons, some of our theming, all of our design elements. If we think about how we are essentially composing up front and what are the basic building blocks of doing those things, write out different surfaces, or more composed elements, and so on.
This is how you can take this monolithic library and break it down to components, and there are several benefits for using those components.
First of all, we need to understand that each of these components is independently released and has a specific semantic version. Meaning that when consumers use those components, they essentially pick the components they want in their application.
Moreover, updates come on each component. So instead of having a large release cycle for the entire design system, what we find is that we can have much more rapid releases on smaller parts of the design system of those components, that only impacts the specific areas where that component is being used by a specific team or in a specific app.
Changes on components also become cheap as our feedback loop becomes that much easier. If I can just iterate on the base theme and get feedback and do a change on the base theme alone, which is then composed to other places, I get a far more efficient workflow. I don’t have to go through and check everything else. I know that composability works for me. I can just change this one little thing.
It also brings into play a unique case where you can also have some non-developers iterating with you on different things. A designer can quickly go into this token list and update a very specific column number. And we can evaluate that and push that forward. It makes our feedback become that much shorter.
Moreover, the smaller and more concise components that we have which can then be composed into larger composite components have more streamlined and simple APIs. So, instead of having very robust and wide APIs on each component, we have the most simplified set of APIs with more compositions, making it easier to use, easier to discover what it does, and less likely to break.
In a sense, once we build this component system, it makes it so we can unlock a flow for a gradual adoption model for those components.
We can break down an adoption of a large design system into small, sprint-sized items that each team can decide on the priority, or decide what they want to use. It’s not just a one-size-fits-all where you have this massive thing you have to put into place, and it changes how you do things.
You can break down and build a roadmap for adoption, so you can look at one team and say ‘with your team, maybe it’s easier to start getting the theme and the icons implemented and then go ahead and grab the grid system, fonts, and different sizes, and only then at the end you can start building or using the buttons, drop-downs, footers, headers, and more patterns’.
Because we are building those independent components that are made to be composed together often, one of the adoption issues that we discussed is whether that design system has patterns for the problems that me as a consumer has. For example, if I’m in an organization where my team maintains a system that is heavy on dashboards and data analytics, and the design system does not support or does not have dashboards, graphs and other patterns, but it does have themes, sizes, grids, whatever, I can take those and only replace my color palettes or my grid systems, and have my graph systems or dashboard systems to just adhere or be more concise with the rest of the UI/UX of the overall brand. This way, I can compose my own unique solution that solves my own unique use case, and I don’t really have to wait until the design system team builds something similar.
And with that, we can even enable this enterprise-wide Component Economy, which in a sense can strike a new balance between the product team autonomy that we want to drive to allows them to move forward fast, and the consistency that we also need from working within the design system that needs all of the apps in the organization to have the same, or at least a consistent, UI/UX experience.
From the top we want to create a system that allows us to govern and understand which components are there to allow this collaboration and discoverability of all of these components. But then from the sides, we have two major types of stakeholders. We have the team that builds the design system, or at least maintains the UI/UX consistency, they would push standards in the form of independent components into that economy.
Those standards can be far more than just the buttons, drop-downs, tokens, and so on. They can also be templates for new components, build configurations components, or the entire development environment for building new components. And just providing the building blocks, starting small with the minimal amount of things they need to provide, and even go horizontally to support more use cases. So, for example, if we ever decided there is a need in the organization to build more graphs, maybe the design system can then create a new domain for the design system with just basic graph elements.
And then on the other end, we have product teams that, for one hand, join the composable building blocks that can be more easily adapted by themselves for the applications, and build concrete solutions. And on the other hand, also be able and be empowered to share their own composite components that solve concrete problems from their end.
So, if for example, the design system team has a standard for what a table should look like, maybe there’s a specific product team that needs a table that allows sorting, or drag and drop for columns, or your headers or footers. And the design system is not about to produce that because it’s not on the roadmap, then the specific product team can create their own domain of components. And they’ll create a composite component that solves the specific problem they have.
This way, instead of force-feeding this solution, the design system provides, from the bottom, a set of standards to build on top, and from the top, a way to govern and understand what’s going on, and make sure that things remain standardized. And all of it only by breaking down everything to a component level, making sure that all components fit with one another, can be composed with one another, and so on.
With this approach, we need always to remember that there is no such thing as a co-component, right? All components are equally composable. There is also the notion of you know, implementing the single button to be the only button for the organization, is something that while often we want, it’s very hard to achieve.
So, if the design system provides building blocks for multiple types of buttons, then product teams can build the buttons they need. And also, we can all try and think about naming buttons that fit our business use case.
So, instead of arguing over what is an atom, what is a molecule, what is an organism, and what can be composed of what, all components in a Component Economy are of the same size. And all components are meant to be composable. This changes often how we think about the UI composability and what is possible for the larger whole.
So, before I wrap things up, if this is something that is interesting for you and this approach makes sense, then my the main takeaway that I want you to take from this is try and focus on adoption for design system and those elements on day one. Don’t wait to have a robust system of components ready-made for everyone. Try to bring in value from a single standardized item.
So, if you already have a design system that you find how to get adoption to, try and simplify that. Wrap it in abstract away a lot of the complexities to a level of a very simple component that other teams can quickly adapt. Maybe your design system is already very modular but this is how to obtain because it’s so fast. Try to boil it down to a specific value point, like, color palette, like, the company logo, so on.
If you are starting from scratch, don’t try and build everything at once. Choose one component, implement that component, and get that component used by one, maybe two teams. And start from there, show the ROI in value, not only for the organization but for the specific teams that use that. It will make it that much easier to start and build this in a more trustworthy relationship with different teams in the organization through the value that we’re providing.
