4 ms·

> Culture Amp was well on its way to doing this in 2018, when things started to get hard for the recently-formed Design System team. This is the problem right

> Culture Amp was well on its way to doing this in 2018, when things started to get hard for the recently-formed Design System team. This is the problem right there. Design system teams never work well. A design system that’s complicated enough to need a dedicated team always creates more friction than it’s worth. Turns out that it’s really hard to standardize UI components in a way that makes them flexible enough to be used across different teams. The only design systems I’ve seen work well are the minimal ones that just define the color values of the visual theme and look of some basic components like buttons but leave the implementation up to the individual devs.

epolanski 3y ago
Hmm, that's not true? GitHub, Atlassian, Microsoft, plenty of greatly and widely used design systems out there. The problem is different: they are huge investments that most non-large companies cannot afford for economic and logistic reasons.
- the_gipsy 3y ago
  But those companies are several leagues higher than whatever Culture Amp is.
  - joneil 3y ago
    I work at Culture Amp and was once team lead of the Design System team. Its not hard to justify the team. If 4 front end engineers in a design system team can solve some common problems (writing components, improving accessibility of existing components, writing docs, answering technical questions etc) in a way that makes 40 product facing front end engineers more effective than 44 who don't have access to the team... then the team is a net positive. At our scale we'd need to give a 10% improvement in efficiency to the product engineers. Both the engineers in product teams, and the various levels of leadership, have seen enough to believe we're making at least that much of a difference. Like almost any other company... measuring that accurately is a nightmare (and would require a significantly larger team just to measure ) but its a safe enough bet that we continue to invest in it.
    - the_gipsy 3y ago
      The problem, with something like a Design System and many other aspects of organizational management, is that efficiency measuring tends to ignore the overhead, the death by a 1000 papercuts, and only focuses on the sweet points.
- brahbrah 3y ago
  Just speaking it off my ass here, but it could be the scale of those companies that make those teams viable. Like let’s say you have some standardized systems that can cover the use cases of 20% of your teams. If you have 1000 teams vs 10 teams, covering 200 teams might make economic sense, but 2 teams wouldn’t
marcelr 3y ago
I’ve seen this at 2 companies so far and tend to agree. At this point if your design system requires more than css its probably too complicated. Maybe design systems work when you are the size of google, etc, but otherwise they are way more work than people seem to believe.
joeblubaugh 3y ago
There’s also the part where they just let teams get away without fulfilling their responsibility to update both versions of a component and just let their tech degrade.
JackMorgan 3y ago
I'm at the point now where I think a design system team is huge mistake unless you've got 25+ people to permanently staff it. At best the team will provide more consistent UI/UX. At worst they will slow all other teams to a halt with poor documentation, bugs, and broken libraries. I've seen three different ~100 person companies throw decades of person years into building out design systems, each to eventually throw it all out. By which time many teams have been forced to adopt the half finished project, so now they've got to tear it all out. We all know now not to build our own databases unless there is an extremely unusual need. In another decade or two we'll say the same thing about design systems. There's nothing wrong with some CSS colors and basics. But you'll only invite ruin if you try to build out (or wrap) React or Angular libraries. I'd guess right now that a full design system library takes about 25 person years to complete and 10 person years per year to maintain. By which time the target language and libraries will have changed so much you'll have to start over at the beginning and start upgrading. Every company I've seen try this staffed the team with about 5 people. So they've got about 5 years to get to 100%. What has changed in the front end in the last 5 years? I know one design system team that started 5 years ago on an Angular 1 design system. No they don't have Typescript, no it doesn't work in Angular 16. I know another design system team that started about 6 years ago in Angular 1, then restarted 4 years ago in Angular 2, leaving most of the company on the Angular 1 version which was about 40% complete. Then 3 years ago they decided to stop forward progress for a year to go back and add Typescript types to existing components. They still aren't 100% on the Angular 16 version. (I think Typescript is great, but I'd guess it adds at least an extra 5 person years to the timeline, since you have to be pretty great with Typescript to accurately apply it to a design system.) All this to say, building out wrapper libraries for a design system is _really hard_. Just the documentation is probably 5 person years of work. The whole thing is expensive, tricky, and error prone. Unless you can staff 5 teams of 5 permanently, the front end just changes too fast to keep up. The ecosystem will look so different in five years, you'll need a whole division working forever to keep up and move to new tech while simultaneously maintaining the old versions. And heaven help you when your designers get tired of the look of it after a year and want to redesign it all again. Because they will. (Wasn't that the point of all this, easy changes to the UI?) Now you've gotta go back and update all the half finished Angular 1 code and release a new version, along with your half finished Angular 16 library. The golden path here is to just provide some basic CSS for buttons, tables, uls, inputs, etc, along with documentation and a site that shows it all in use. Put it up on a CDN with a version in the name so teams can upgrade easily. This whole project could be done in under two person years, just a UI engineer, a designer, and maybe a QA person. It's quick, and after it's over, everyone can work on something else. There's no need to keep a big team staffed forever. There's no need to do a rewrite for React Hooks or whatever. The CSS will work forever. Next year when the designers want a new set of colors, spend a few months to have someone release a new version. Don't change any of the CSS selectors. DON'T CHANGE ANY OF THE CSS SELECTORS. Everyone bumps the version on their CSS src tag and it just works. Easy day.

epolanski 3y ago

Hmm, that's not true? GitHub, Atlassian, Microsoft, plenty of greatly and widely used design systems out there. The problem is different: they are huge investments that most non-large companies cannot afford for economic and logistic reasons.

the_gipsy 3y ago
But those companies are several leagues higher than whatever Culture Amp is.
- joneil 3y ago
  I work at Culture Amp and was once team lead of the Design System team. Its not hard to justify the team. If 4 front end engineers in a design system team can solve some common problems (writing components, improving accessibility of existing components, writing docs, answering technical questions etc) in a way that makes 40 product facing front end engineers more effective than 44 who don't have access to the team... then the team is a net positive. At our scale we'd need to give a 10% improvement in efficiency to the product engineers. Both the engineers in product teams, and the various levels of leadership, have seen enough to believe we're making at least that much of a difference. Like almost any other company... measuring that accurately is a nightmare (and would require a significantly larger team just to measure ) but its a safe enough bet that we continue to invest in it.
  - the_gipsy 3y ago
    The problem, with something like a Design System and many other aspects of organizational management, is that efficiency measuring tends to ignore the overhead, the death by a 1000 papercuts, and only focuses on the sweet points.
brahbrah 3y ago
Just speaking it off my ass here, but it could be the scale of those companies that make those teams viable. Like let’s say you have some standardized systems that can cover the use cases of 20% of your teams. If you have 1000 teams vs 10 teams, covering 200 teams might make economic sense, but 2 teams wouldn’t

marcelr 3y ago

I’ve seen this at 2 companies so far and tend to agree. At this point if your design system requires more than css its probably too complicated. Maybe design systems work when you are the size of google, etc, but otherwise they are way more work than people seem to believe.

joeblubaugh 3y ago

There’s also the part where they just let teams get away without fulfilling their responsibility to update both versions of a component and just let their tech degrade.

JackMorgan 3y ago

I'm at the point now where I think a design system team is huge mistake unless you've got 25+ people to permanently staff it. At best the team will provide more consistent UI/UX. At worst they will slow all other teams to a halt with poor documentation, bugs, and broken libraries. I've seen three different ~100 person companies throw decades of person years into building out design systems, each to eventually throw it all out. By which time many teams have been forced to adopt the half finished project, so now they've got to tear it all out. We all know now not to build our own databases unless there is an extremely unusual need. In another decade or two we'll say the same thing about design systems. There's nothing wrong with some CSS colors and basics. But you'll only invite ruin if you try to build out (or wrap) React or Angular libraries. I'd guess right now that a full design system library takes about 25 person years to complete and 10 person years per year to maintain. By which time the target language and libraries will have changed so much you'll have to start over at the beginning and start upgrading. Every company I've seen try this staffed the team with about 5 people. So they've got about 5 years to get to 100%. What has changed in the front end in the last 5 years? I know one design system team that started 5 years ago on an Angular 1 design system. No they don't have Typescript, no it doesn't work in Angular 16. I know another design system team that started about 6 years ago in Angular 1, then restarted 4 years ago in Angular 2, leaving most of the company on the Angular 1 version which was about 40% complete. Then 3 years ago they decided to stop forward progress for a year to go back and add Typescript types to existing components. They still aren't 100% on the Angular 16 version. (I think Typescript is great, but I'd guess it adds at least an extra 5 person years to the timeline, since you have to be pretty great with Typescript to accurately apply it to a design system.) All this to say, building out wrapper libraries for a design system is _really hard_. Just the documentation is probably 5 person years of work. The whole thing is expensive, tricky, and error prone. Unless you can staff 5 teams of 5 permanently, the front end just changes too fast to keep up. The ecosystem will look so different in five years, you'll need a whole division working forever to keep up and move to new tech while simultaneously maintaining the old versions. And heaven help you when your designers get tired of the look of it after a year and want to redesign it all again. Because they will. (Wasn't that the point of all this, easy changes to the UI?) Now you've gotta go back and update all the half finished Angular 1 code and release a new version, along with your half finished Angular 16 library. The golden path here is to just provide some basic CSS for buttons, tables, uls, inputs, etc, along with documentation and a site that shows it all in use. Put it up on a CDN with a version in the name so teams can upgrade easily. This whole project could be done in under two person years, just a UI engineer, a designer, and maybe a QA person. It's quick, and after it's over, everyone can work on something else. There's no need to keep a big team staffed forever. There's no need to do a rewrite for React Hooks or whatever. The CSS will work forever. Next year when the designers want a new set of colors, spend a few months to have someone release a new version. Don't change any of the CSS selectors. DON'T CHANGE ANY OF THE CSS SELECTORS. Everyone bumps the version on their CSS src tag and it just works. Easy day.