Custom when it's needed - making pre-built solution work for clients brand

Two to three years ago, we started building a design system from scratch for one of our long-term clients - a system that will reduce design inconsistencies, scale across multiple products and will narrow the gap between design and development. We’ve seen firsthand how much faster projects move when there’s a proper design system in place.

We started with building the foundation - creating spacing scales, custom primitives, typography, semantics and set of the custom-made components. It was a good start, but it quickly became clear the project would need constant maintenance and take way more time than we wanted to spend on it.  So, we needed to revise our process

This year, we decided to try a different approach and bought a mature, ready-made component kit. It came with a full component library, built-in accessibility, a token system and the Figma UI Kit we could use to make the life of design and development easier.

It seemed like the best of both worlds until we started auditing it more closely.

‍

What Didn’t Work

For development it looked quite easy to use and maintain, but the design team struggled to adapt the UI kit to meet our needs and reflect our client’s look and feel. The token system especially became a pain point.

We were fighting with the bases:

• Mismatching token naming convention and lack of good semantic structure
• No easy way to add extra token sets
• Customization risks - updates could easily break our overrides
• No native support of multiple brands and themes

‍

We had the option to adapt and make compromises, maybe drop or adjust parts of the brand to fit the system, but delivering something "almost on-brand" didn’t feel like the right approach.

‍

Different approach: custom tokens, pre-built components

Instead of reverting back to all custom solution, we decided to split it in two.

We are keeping the pre-built components, they were solid and accessible, and replacing the token layer with our own. That meant rebuilding our token system and remapping it to the components.

‍

We focused on:

• Tailored primitive color
• Semantic tokens
• Clear and consistent naming
• Easy to understand token structure, that can scale in the future

‍

We believe that this hybrid approach will give us the flexibility we need to deliver a system that’s both scalable and truly "on-brand" - without giving up all the benefits of a mature component library.

There’s still a lot of work to do and we’re not done yet. But once we’ve rolled it out fully, we can share a follow-up with the results what worked, what we’d change, and what kind of impact it had on scalability, team pace, consistency across the products and most importantly, how much maintenance time we've saved.

If you're in the middle of figuring out design workflows or just trying to make your team run smoother, you might want to check out how to onboard a designer efficiently in a product team, the difference between mentoring and coaching in design teams, or what a UX audit is and when it’s worth doing one. Could be some useful stuff in there depending on what you're working on.