The Gradual Design System: How We Built Slack Kit

In 2016, Slack was two years old and already used by millions of people. Our codebase had grown rapidly, and like many companies that focused on product/market fit, our code was built in a way that favored time-to-market over maintainability, consistency, or reusability.

What does a button look like in Slack? How do you build it? What words do you put in it? It was up to individual teams to make these decisions.

I am really surprised that their engineering org took so long to see the long-term payoff of common CSS components/styling when it comes to linting, minifying, and caching on web and sizing/spacing/scaling on native mobile. I am even more surprised that their product team didn't consider a unifying "brandfeel" from the get-go. If your goal is to _scale_ and _scale fast_ while being a judicious steward of VC monies... wouldn't you want to eliminate as much wheel-reinventing as possible?

I say this without any gratuitous negativity/internet holier-than-thouism... I just wouldn't expect this level of "bespoke craftsmanship" for a solved problem like common theming/styling in a engineering org at their series F stage with Accel, a16z, and KPCB already on the cap table. Weird.

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 :-)

There's an interesting trend in GUI design, where systems fluctuate between simplicity and complexity.

It seems thing naturally become more complex to meet user's requirements, this is pleasing at first. When things have gone too far people see simplicity as a better way to unify the system.

This has also happened on the macro scale as an industry trend in Web design. From the diverse designs of the 2000's to the simplified bootstrap era of 2010's. Material design then brought back some diversity with many more colors and shadow options, but it seems design systems like Slack Kit and [1] ant.design (which have less colours and no shadows) are swinging the pendulum back from complexity to simplicity...

I suppose design is cyclical in a way

[1] https://ant.design/

It seems like Slack built themselves a toolbox like Bootstrap or Material Design Lite or similar but for their own style guide.

I've been wanting to do the same type of thing for a while but I feel like the development workflow and tooling is somewhat lacking and it's kind of hard to get people on board. Everyone always wants something a little extra custom, or doesn't want to jump through the hoops putting their styling into the main repo instead of in their react app.

Does anyone have any suggestions for tooling to enable us to build something like this?

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