The Gradual Design System: How We Built Slack Kit • Hacker News Board

Re: The Gradual Design System: How We Built Slack Kit

#11

Post by steve_adams_86 » Thu, Sep 12, 2019, 11:08 PM UTC

ng12 wrote: post #9

SeeDave wrote: post #7

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

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.

Re: The Gradual Design System: How We Built Slack Kit

#12

Post by SeeDave » Thu, Sep 12, 2019, 11:28 PM UTC

heyitsgarrett wrote: post #10

SeeDave wrote: post #7

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

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 ot…

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.

Re: The Gradual Design System: How We Built Slack Kit

#13

Post by gitgud » Thu, Sep 12, 2019, 11:44 PM UTC

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/

Re: The Gradual Design System: How We Built Slack Kit

#14

Post by eigenloss » Fri, Sep 13, 2019, 1:02 AM UTC

gitgud wrote: post #13

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 sim…

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