The Gradual Design System: How We Built Slack Kit

This design system failed to deliver the highly requested feature of a desktop dark mode for five years (until today): https://twitter.com/SlackHQ/status/531941157283315712?s=19

It's more likely that dark mode wasn't prioritized at the product level. I doubt it took their designers five years to figure out how to adapt the design system to dark mode.

Bootstrap has some JS but is mostly a library of CSS classes. They built themselves a library of React components that they can use to compose UI. I've built stuff like this using React and Vue, without any additional tooling. IMO it can be a great approach but only if there's' a cohesive agreement on the design within the company, IE it doesn't work that well when the stakeholders don't "stick with it".

A design system is one of those problems that seems really simple to both conceptualise and implement, but in practice is really hard.

I've attempted it so many times, and whilst I learn things and get a bit better with each attempt, I've never succeeded, or have only succeeded for a short time before things get back to being messy again.

The problem is the edge cases. It's just like writing an API, covering it with tests and being sure it's done, then someone coming to you with a new feature idea and you have to tack something on awkwardly or add a special case to make it work, just this once.

Fast forward a year of this and your shiny new API is now the legacy mess everyone wants to refactor. Exact same thing happens with design systems and component libraries. You can't design for the UI usecases that haven't occurred to you yet, and when they come up, your shiny design system likely won't flex to accommodate that.. so you just tack on that one thing :-)

I wrote this article, and appreciate your framing here. A few things contributed to this effect that I think are a bit clearer with hindsight. Central to this was a lack of clarity between designers and engineers about what the state of things actually was. Designers assumed that engineers had been doing some of this work in building shared components, while engineers trusted that designers were aligning with each other. A lot of that happened organically when we were smaller but as we grew faster, those assumptions start to break. Eventually, we were far along before recognizing how much some of our patterns had diverged.

We had a pretty good idea what needed to happen to fix it, but there was a ton of work happening to maintain our same quality at scale across all of our feature teams. When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.

In the end, it's difficult to get people to agree to one thing, much more so when you're adding more and more people to the mix. We're in a much better place now. More than just having an interface library, we've created a framework for debating the various parts of the system and reinforcing that understanding that was missing early on.