How Distributing Your Design System Can Save You Time and Money
Over the past several years, we have continuously embraced design systems when building production-ready applications as it encourages developers to improve code re-usability, quality, and efficiency. They also enhance the user experience, leading to happy and satisfied customers.
Simply put: A good design system can save money and make money. Win-win.
While design systems theoretically hold immense potential, their practical adoption by product teams can be a formidable challenge.
Why Do Many Design Systems Fail?
A design system is a collection of reusable components driven by a defined standard that can be used to build applications at any scale. Design systems are commonly built and maintained using a top-down, monolithic approach by a centralized team within the organization. Nevertheless, they are meant to be used across all teams. This approach creates a generic “one-size-fits-all” component library for all product teams to adopt.
However, adopting design systems with this pattern causes several issues and bottlenecks:
- Since your design system is controlled, the necessary components might be unavailable. Moreover, by the time you decide to include it, product teams might have already implemented it on their own.
- Your design system draws requirements from product teams. However, in a monolithic approach, the requirements get queued for various reasons, such as priority, cost, and compatibility — ‘coupling’ the product teams’ roadmaps with that of the design system team.
- Adopting a design system limits a team’s flexibility as they cannot contribute and must wait for the design system team to introduce new components. In addition, this process can take multiple iterations and may not perfectly meet the unique needs of multiple teams.
- A single team owns your design system. Therefore, accelerating delivery and scaling your design system means increasing the headcount design team.
- You need to invest effort continuously and large sums of money into the design system to ensure its growth. The minute you stop, it starts to rust and is quickly deemed ‘legacy code.’
The end result? Many product development teams within organizations avoid using the corporate design system due to these challenges, opting instead to create their own components.
Unfortunately, this repetition not only slows down their cycle time but also leads to added redundant coding and inconsistencies. The end result is higher development costs for the organization, often three times the budgeted amount because:
- The company has to invest money to design and build the design system.
- The company must bear the costs of product teams developing their design system.
- The company has to bear the cost of inconsistent user experiences.
With high costs, it becomes challenging for organizations to justify this investment over time — and the design system quickly becomes legacy.
Hence it is crucial to identify ways of reducing costs when designing and implementing design systems.
Well, how can we save money?
One such method that companies can adopt is to distribute their design system.
What is a Distributed Design System?
A distributed design system is a shared design resource that is utilized by multiple teams and products in various projects. Unlike a monolithic design system that is owned by a single team, a distributed design system is accessible to all members who are encouraged to contribute, leading to increased scalability and adaptability.
However, to maintain consistency and prevent confusion, it is crucial to establish a well-defined governance and review process, which will be described in more detail in the subsequent chapter.
But wait, how does that save costs?
A distributed design system could decrease an organization’s total cost of ownership as its development and maintenance can be shared by several product teams rather than one dedicated team. Some of the several reasons that support this are discussed below.
1. Reusing Design Components
More often than not, product teams are invested in contributing solutions to common design problems. Therefore, they may develop a set of reusable design components catered to the design problems they can share across the organization and even reuse.
Distributing your design system can help everyone create and utilize existing resources within your product teams and significantly reduce the development cost and effort in the long run. This is because the teams will have a boilerplate design to start with every time they decide to use the design system.
2. Reduce The Development Burden
Sometimes, the “top-down” centralized approach to building design systems burdens the team. This is especially true when your design team gets requests from several product teams to add new design components. Hence, they will stay caught up on their work or even fall under pressure trying to keep up with the feature requests and may get overwhelmed.
Therefore, when faced with these situations, the organization must incur additional costs and enlarge its design team to accommodate the increased demand.
In a distributed approach, the development and maintenance is shared across the organization. This means that everyone contributes to the design system. As a result, the burden on each person is reduced and the design system is able to scale more sustainably.
3. Adding Product Value
Distributing the development and maintenance of a design system has benefits for product teams. It allows them to tailor components to their specific priorities and needs. For instance, they can create reusable and standardized components for typography, themes, and generic UI elements like Cards. This saves time and resources in the long run, as these components can be reused throughout the team’s lifecycle.
4. Larger Returns on Investments
Companies that utilize distributed design systems shift their investment focus to the actual product teams and not a single centralized design team. More often than not, this creates a more significant return on investment than centralized design systems for two main reasons.
- With improved product teams, their capability of contributing to the design system ultimately helps build the cooperate design system faster to meet the organization’s ever-changing needs rather than having a lengthy design backlog.
- Improved end-products: With more significant investments in actual product teams, they can increase the effort to build end-products to support their growth further.
Therefore, by adopting a distributed design system, not only can you ensure scalability but also foster growth within your product teams, leading to a double win at a reduced cost!
Adopting Distributed Design Systems
After understanding the cost benefactor of distributed design systems, it’s essential to keep in mind that a design system is generally built around the ideology of solving many independent problems in a single attempt.
Solving problems in a single attempt means developing reusable code that product teams can consume rather than increasing the cost by reinventing the wheel.
Therefore, organizations can adopt the distributed design system and let product teams design and develop components that address a single problem. By doing so, an organization could efficiently encompass a standardized component-driven system that distributes its rules.
With a platform like Bit, a dedicated team can develop UI components to ensure standards and consistency. At the same time, autonomous teams can innovate rapidly by having the flexibility to meet their specific needs without being coupled to the design system team’s roadmap. So, let autonomous teams innovate rapidly while standardizing components and design to ensure standards and consistency.
And organizations do not have to rush with the implementation process. Instead, they can choose to implement it incrementally.
You can start with a single team or project and gradually expand to the entire organization. For example, you can use Bit components in an existing project and progressively move to a modular, distributed architecture with teams getting more and more autonomy.
By separating components from a centralized “one-size-fits-all” design system and giving teams more control, you can lower costs in terms of time, effort, and overall investment. Additionally, this will result in improved developer efficiency, striking a balance between autonomy and consistency.
Conclusion
Selecting the right design system can be a challenge for organizations. But, adopting distributed design systems provide the capability of creating composable design systems that help maintain brand consistency across projects. In addition, these solutions offer the adaptability and scalability of a centralized design system but at a lower cost.
Bit simplifies the design process by facilitating collaboration on a shared design system. This enables organizations to rapidly and effectively scale their design system and maintain consistency across all projects.
I hope this article has been informative and helpful for you.
Thank you for reading.
