How to gain true adoption for your design system by developers, and everyone else…
The truth is that designer-developer collaboration has always been a pain point. And not just designers; product managers, marketers and everyone else should also be included in the visual aspects of the development process. This is a key part of what we’re doing at Bit’s collaborative component platform, which gave us the opportunity to learn (and share) a lot about this topic.
Much of this gape is created between canvas-based visual design tools like Sketch to where code is, like GitHub. Designers can’t really see what’s going on inside a GitHub repository, and developers can’t really use Sketch libraries.
Today, modern design systems are built with modern components. The beauty of these components, built with frameworks like React or without a framework, is that they have the potential to bridge the gap between being a design element and being a fully functional unit in real code.
To create true collaboration between designers and developers, you should leverage components and turn them into the focal point where design and code meet. This sounds complicated, but using the right tools, methodology, and collaboration it can be simpler than you might think. We’ll also show how to create a collaborative reusable component system to achieve this.
Designers will benefit from being able to keep your brand and visual language consistent across different products and applications, keeping users happy and well-originated. Developers will enjoy less frustration and will be able to standardize and reuse components and their development across projects. The team will become more productive, and will deliver faster and better.
So what is your design system, really?
 and props to [Astasia Myers](undefined)](https://res.cloudinary.com/practicaldev/image/fetch/s--YEE3lN6g--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://cdn-images-1.medium.com/max/2000/1%2ApJVdKtpSy3cs5DEi1widMw.jpeg)
Source: Memory leak and props to Astasia Myers
The answer depends on who you ask, and that’s the problem.
A designer will say that your design system is managed in tools like Sketch Libraries or Invision DMS, and is composed out of visual component elements and a style guide that defines the rules of your visual language.
But, ask a developer, and they will say that your design system is your GitHub UI library and is made of components grouped together in a repository. This repository is published as a package, which is used in your different apps.
Both are equally right and wrong, and the only certainty is this- as long as designers and developers struggle to communicate and collaborate over a unified source of truth, your users will end up experiencing a less consistent visual language and developers will have a hard time standardizing your UI.
The truth is that your design system is what your users experience. This means that the only real source of truth for components is the code itself.
This doesn’t mean you have to give up Sketch and start coding, not at all. It just means that if you want to achieve adoption for your design system, you have to collaborate with developers over code- in a visual way. We’ll soon show some tools that can help make that happen, and even make it fun.
Why is it hard for developers to adopt component design systems?
When a developer is asked to implement a design system, they have to do much more than just translate a design into code. They have to build the right foundations for a standardized and collaborative component ecosystem.
Building and distributing components means they have to get other developers, which are building your apps, to adopt their components. Over time, they have to maintain and update the components, add new components, and make sure everyone uses these components in their code.
You can think of two different types of “developers” which will have to engage with the components you design:
Component (library) builders: These developers are given the complicated task of translating your design into code, then distribute the components for app builders, and make sure they are adopted and standardized across all your organization's projects. They are the ones who build the UI library, document and update it as the design evolves.
App builders (component consumers): These developers are building the actual user-facing apps of your organization or team. They are the “consumers” of the components in your design system. If you don’t get them to adopt your components, your users will not get it either.
Why app-builders won’t adopt your components?
Visual design system built from real React components in bit.dev
To get developers adopt components, you need to build a reusable component system that is adopted by different teams and used across different apps.
This can be hard for various reasons:
Discovering components: App builders need to be able to quickly find and choose components, learn how they work, view relevant information like size or dependencies, and view the API reference, props etc. A good solution is a reusable component collection with bit.dev.
Adopting components: App-builders need to be able to install and use only what they need, without having to add an entire library that bloats and slows down their apps. They only want to get updates to what they really use, and not the whole library every time.
Modifying components: App-builders need to be able to use components without having to couple their apps to the development of the library. They can’t dive into the whole library every time just to make a pull-request. They need to modify components and suggest updates right from their own projects and make sure the modified code runs and build right in the context of their own app (currently only possible with Bit).
Building a component system that gets adoption
The best solution is to create a reusable component system that brings together your design system and component library into one collaborative system of reusable components.
This approach means that you build a system where all components, from your libraries and apps, are organized in one place. Developers can easily discover, learn, consume, adopt and update components in their apps.
Designers can instantly view and monitor the real implementation of their design in actual code components, and visually collaborate to ensure that all implementation meets the design system and style guide.
The organization gain more adoption and standardization of components across project, and ensures UI/UX and brand consistency across apps.
How to build a reusable component system
A reusable component system
Currently, there’s one tool that lets you build a reusable component system, called Bit(GitHub). Bit is a dev-tool that isolates components from libraries and apps, and makes sure each can be built, tested and run in any other app. It also lets you develop components from different projects and sync changes between them. It’s a super-useful power tool for building component systems.
To create your *reusable component system *you can use bit.dev, which is the component hub “as a service” (free for personal or open-source use). There, your team can quickly set-up a reusable component system to build with.
Create your own reusable component system
Learn more about building a reusable component system
You can explore some open source reusable component systems here
Component (library) builders can instantly export their components to a reusable collection so that everyone can find, use and collaborate over these components. Thanks to Bit’s open-source tooling, components are exported as standalone units, with all needed dependencies and configurations for reuse. In fact, the monorepo experience for component builders in enhanced with the ability to build, test, version and distribute isolated components.
App builders can easily find shared components, filter them by data like size or dependencies, view props and API references extracted from the code, and consume components right into their own app. Moreover, they can import components to suggest updates right from their own applications. Since each component is isolated, it will run and build in the new app “out of the box”. This means more adoption, standardization and reuse for components.
Since all components are also visualized in your bit.dev system (examples), designers too can now see exactly how each component is implemented in your real code, monitor changes over time, and collaborate with developers right over the real code they write to build your UI. Since each component is rendered in a live editable playground, this process becomes interactive and you can save different visual examples for components and align your design.
Visualize each component for designers to see how code is implemented; use what you see
To sum-up some of the advantages:
Component builders get the tools to build, distribute and get adoption for their components across projects and apps. Their own monorepo experience for the UI library also becomes better with Bit.
**App-builders **can easily find and choose components. They can install and update only what they need in their apps. They can suggest updates right from their own projects. Each component can be developed, run, built and tested in any project’s environment. Adoption becomes much simpler. Components are standardized across projects which is very useful.
**Teams **can colalborate over reusable component systems instead of jumping back and forth from Sketch to GitHub, and continuously make sure they meet the needs of both design and development. Other stakeholders like product and marketing can collaborate too.
**Users **get a consistent experience across your apps, successfully interact with your apps, feel familiar with your brand and are happier overall.
Build a living component ecosystem and grow designer-developer collaboration
One particularly important aspect of a reusable component system is the collaboration between designers and developers.
Many tools aspire to turn visual images into code. Honestly, I don’t think that this will be possible anytime soon, and developers won’t adopt this code.
But, you can definitely visualize the code you write. When the components in your reusable system are visualzied from the real code itself, and what you see is really what developers use in their app, you can create (maybe for the first time) a true common ground between designers and developers.
Component builders, app builders and designers can all work together to build your reusable components, update and monitor changes, and create a collaborative component ecosystem in your organization.
Feel free to jump in and create your own reusable component system:
Share reusable code components as a team · Bit
*Easily share reusable components between projects and applications to build faster as a team. Collaborate to develop…*bit.dev
Only by thinking of your design system as a living, breathing and evolving ecosystem you can get true adoption and sustain it over time. Tools like bit.dev can help you achieve that, so that everyone can build together faster and better with the same shared components. It’s simpler than you think.
Explore open-source reusable component systems
Thanks for reading, and please don’t hesitate to comment below, share your own experience or insights and ask anything! Cheers 🍻
Medium
Top comments (2)
What I like most about building a design system is consistency.
Unfortunately. Having a cloudy mess of understanding of what consistency means reducing speed for the company to deliver a product. The previous company I had worked on has an inconsistency of using Design System.
"Is it bootstrap? Material Design? Ant Design?"
I tried to explain to them that having a design system is fundamental to the ecosystem of their application. But sadly, they want a functional product with a bizarre codebase
That must be great Article thx.