Design Systems: building custom vs building on top of an open-source design system
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 rely 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…
