The Gradual Design System: How We Built Slack Kit | Hacker News Reader

The Gradual Design System: How We Built Slack Kit

slack.engineering

72 pointsrossharmes13 comments

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

>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 lot of companies don't take front-end seriously. They don't invest in hiring the guys who will ask these questions and will prefer to pad their ranks with fresh-faced college grads.

You're not wrong. Most of the fresh faces I've worked with have been eager to just make it to their first real project, whatever that takes. Asking questions can get in the way of what leadership will see as progress, and they might not be aware of which questions to ask yet (because they haven't screwed up enough yet, haha).

There are plenty of fresh-faced college grads with good sense to ask those questions though, and I've worked with them. The problem can also be management who hears a good idea, finds out it'll take longer in the short term, and says no - let's move fast and break things or whatever motto you're familiar with.

You can have good foresight and know your team needs proper scaffolding to scale but never get the green light to get it built if the people managing you don't see the value in it.

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.

Hey, thanks for your response! Great article and you guys are definitely in a good place now (yay Dark mode!) Your iterative approach to course-correction was absolutely the way to go so hats off for a job well done.

>When you're focused on maintaining and building toward better reliability, it's harder to slow down and centralize principles, components, etc.

Been there, done that, got the T-Shirt. Routing in Angular, API design and versioning, CMS integration, and more. I get it.

>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.

There are probably a dozen relevant Dilberts on design-by-committee which are probably amplified by the egos and inexperience of dozens of 2x-year olds working at $hottest_unicorn. I strongly suspect that you are a very kind, patient, and understanding man.

>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.

Congratulations, again. My sincerest apologies for focusing on the 'start line' when your article was about the race. Hindsight is absolutely 20/20 so hats off for a job well done and thanks for the follow-up.

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?

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".

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/

There's no difference between this and any other fashion choice like car styling, clothing, shoes, house painting, hairstyling, or furniture.

Whatever "technological" or "UX" advantage marketed via blogposts like this is simply a veneer over the standard human competitive strategy: 'what I have is more fashionable than what you have, so pay me.'

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.

Can we open code snippets in the application, instead of forcing a browser login?

Reply on news.ycombinator.com