Technology teams must support the Design mandate in the journey of creating, adopting, and maintaining a design system. At the risk of limiting the design team's innovation capabilities and UX ambitions, engineers might need to find optimizations, enablers, and levers outside of the approaches used in other types of digital projects. One example is the typical decision point: building custom vs building on top of an open-source design system.
Choosing to build on top of an existing open-source design system to optimize cost and time-to-market has the same risk, if not higher, as building completely custom. It's too easy to feel like the right choice; engineering teams are used to relying on third-party libraries to optimize for time and cost in traditional projects all the time.
I have seen many teams failing with Material or Carbon having a final product looking like Google or IBM products - missing the ambition set by the design team. Attempts to customize these libraries to fit the design's vision often led to more time and investment rather than achieving the shortcut desired.
On the other hand, endless debates about conventions, tokens and atoms led teams not to deliver a consumable and effective design system when building it custom. Also, the overwhelming amount of decisions in this scenario often slows delivery, not rarely increasing pressure on the team and reducing quality standards.
Successful design system teams often optimize to deliver the best UX as quickly as possible to customers. They choose a strategy based on incremental releases that enable the adoption process to start sooner. They establish a communication channel with teams consuming the design system to collect feedback and improve it iteratively. Also, they will consider the design system as a product: it's never done; it's constantly evolving.
If an open-source design system does not support the design's team ambition & vision, or creates challenges for the characteristics of successful projects above, then building custom is the way to go. In other words, if the design expected requires more than adjusting the theme options (tokens values), the custom route is a better option.
It's a common mistake to assume it is easy to change and adapt the default components offered by the framework. Teams overlook the complexity since the customization implies reviewing documentation, impacts on composed components, accessibility and quality checks at best. Often it also requires creating more atoms and tokens, which can quickly bloat and add complexity to the maintenance. Customizations often create barriers to keeping the project up-to-date with the original system, missing bug fixes and improvements.
Building custom means you need a proper team and budget to support the design system. More decisions around the stack and tooling will be required to enable the project and adoption. The team will need more support to stay focused on making progress and avoid common traps.
Another false assumption is that building a custom design system means starting from zero. Tooling and resources are available to enable teams to start a custom design system from a more advanced stage that will not compromise the solution in the long run. Radius from Rangle is a good example - it is a collection of open-source tools and libraries that guide and help you to build a custom design system faster.
Creating a strategy for a design system is a complex task that we can help with. At Rangle, we partner with our clients and help them to make better decisions. With the "one team, one goal" approach, we unblock their teams and unlock market opportunities. Hands-on learning opportunities and co-creating design systems mean that our client's teams can build great customer experiences long after their engagement with Rangle is over. In addition, we focus on great processes that are scalable and aren't dependent on hiring star developers or designers but on ensuring everyone in your organization can deliver to the best of their ability.
I'm curious to learn about the challenges and experiences you have with Design Systems. Reach out, and let's exchange ideas.
Top comments (0)