Recently, I provided consultancy to a developer who was consuming a design system rather than building one. A design system had been set up for the first time at their well-established company. The next step was for product teams to adopt it. All good so far. However, as they explained further, it became clear that expectations between the product teams and the design system team did not line up.

I'll break it down into two key areas: The long-term plan for adopting the design system (or its lack of) and what applications could reasonably be adopted in their current state.

Design System Adoption Planning

Even having the opportunity to work on a design system at your company is a luxury. Not everyone gets the chance to heavily revise their entire design language and frontend approach outside of main product work. With that opportunity also comes the chance to be more considerate of the interplay between design and development.

Despite the introduction of a design system, this developer was suffering from the waterfall process that already existed at the company. Throwing the design system over the fence for implementors is going to cause problems more than anything else. Instead, the design system should introduce an opportunity to educate, collaborate and plan.

At Nordhealth, we spent many hours creating roadmaps for adopting the Nord design system into applications, which were followed not only by product teams but also by ourselves. Yes, sometimes, the design system team needs to roll up its sleeves and get involved in the implementation process. The combination of deep collaboration and planning paid off, adoption rose significantly and communication increased across all teams.

Incremental Design System Adoption

If you can get an entire company to use the same icon for something we would consider that a bloggable success

I was talking with colleagues at zeroheight yesterday about how design system contributors and design system consumers often unwittingly attempt to meet in the middle from two opposite ends. One is producing UI that is self-contained and consistent to distribute, and the other is trying to reduce very dispersed UI into self-contained and consistent units. These are two very different perspectives, but they have one common challenge: coverage.

In this developer's case, the coverage was stacked against them. The design system team expected them to implement not only their entire design system but also the underlying framework it was built upon. Before any meaningful UI changes could be made, the developer was expected to — check notes — and change their frontend stack.

Okay, maybe I'm being hyperbolic, but I do think it's a bit of a show-stopper. Not only is it detrimental to this developer's experience of the design system but to anyone who wants to use it. "Never mind a whole framework; if you can get an entire company to use the same icon for something, we would consider that a bloggable success," I said. The design system needs to be adopted incrementally, piece by piece.

With Nord, we had this approach in mind from the beginning and throughout our planning. The design system code is broken down into multiple packages that can be used individually and collectively. Tokens are one CSS file away, and the same goes for our CSS helpers framework. After that, components are just one JavaScript file away, and thanks to the benefits of Web Components, they can be dropped into any frontend framework or stack.

I'll refrain from promoting specific technology choices because what's important is how the design system itself has been designed to be adopted. It's not a sprint; it's a marathon… with maybe some relay in for good measure. Your implementors will thank you for it.

Side note: UI Migration

There's an almost hidden benefit to incrementally adopting a design system and planning those increments over a time period: the user experience. If done correctly, customers will be eased into the new interface over time rather than disoriented when they log in the next morning to see an entirely new UI. This approach isn't for everyone, especially if the marketing team wants to make the most of promoting a "new and improved user experience!"

We did this at Nordhealth, which I nicknamed "UI Migration" at the time. With each step of the design system adoption plan, customers were eased into a new change. Where and when appropriate, we would notify them of these changes and even provide an escape hatch to the "classic UI" if they really struggled. It wasn't completely clear whether this was successful, as our only measure was the amount of support requests coming in, but the count seemed to stay somewhat low.

That's all I have for now. I hope these points resonated with some of you. I'd love to hear if you managed to resolve these same problems or if you just waded in and somehow came out the other side.