4 ms·

One thing I keep noticing about design systems is that they all look extremely difficult to maintain. On the development side, we all know that the more diffic

One thing I keep noticing about design systems is that they all look extremely difficult to maintain. On the development side, we all know that the more difficult/complex a unit testing suite is, the less likely it is to be effectively maintained. All design systems I see are art directed. You have these very nice visual layouts showing each element of the system, with well crafted type explaining each aspect of it. It isn't a generated document; it's seemingly hand-crafted. So my immediate thought is: is this versioned? What happens if it's updated? How should the changes at this stage propagate down to the individual teams who consume this design system? Maybe I'm not seeing the whole picture, but I have a hard time believing that these "design systems" are built for long term sustainability.

crtlaltdel 7y ago
If you look at the code in the repo, each component has comments (jsdoc?) which are parsed and rendered as part of the storybook: https://github.com/flexport/latitude/blob/master/Text.jsx#L66 https://github.com/flexport/latitude/blob/master/Text.jsx#L6... https://www.flexport.com/design/components/Text https://www.flexport.com/design/components/Text
mindcrime 7y ago
I'm intrigued by the possibility of using one of these design systems in some of my own work, but I'm likewise concerned about what it means for the long-term. Especially given that I'm not really a UI person first and foremost, I worry about an excessive degree of lock-in that will be hard to back out later if needed. I haven't tried this one yet, but I'm playing around with the IBM Carbon Design System now for an internal side-project thing... depending on how that goes, I might start using that more widely. On that note, I'd be really curious to hear from anybody who has used Carbon, and is willing to share their thoughts, pro or con.
- RickS 7y ago
  I haven't used carbon as an engineer, but as someone working on design systems, they're overall pretty impressive. For a giant menu of options, see here: https://github.com/alexpate/awesome-design-systems https://github.com/alexpate/awesome-design-systems Atlassian, Lightning, Blueprint, and Polaris are some big names that could be worth checking out. And of course there's always bootstrap. > I'm not really a UI person first and foremost Using another company's component library can be a really fantastic head start, then. Especially if you've got a smaller application that doesn't require the whole kitchen sink. You can build fast with stuff that works, and if down the line you want replace it with in-house components, you've already got a north star of sorts. >I worry about an excessive degree of lock-in that will be hard to back out later if needed. It depends. If you clone the repo and it works for you, you may not necessarily have to keep it updated if you don't want to. I would worry more about being bound to abstractions that are needlessly complex – many of these systems are designed so that small changes to upstream values propagate throughout the system in very deliberate ways, which can make tweaking intermediate values a bit of a landmine. Using a big ass codebase for a couple components means you might have to go spelunking in a big ass codebase.
  - mindcrime 7y ago
    Righteous! Thanks for the info.
dmnd 7y ago
Latitude isn't versioned. Flexport's internal monorepo tracks Latitude's master branch. When we make breaking changes to Latitude, we update all internal call sites too. For example, see https://github.com/flexport/latitude/pull/61 https://github.com/flexport/latitude/pull/61 where we replaced our tooltip implementation. This approach has worked well for about 4 years so far. As for docs, we do generate what we can (as explained by my sibling comment). But some pages (e.g. guidelines) are indeed hand-crafted.
- mikeryan 7y ago
  By updating the tool tip Does the new component propagate out to all sites?
  - dmnd 7y ago
    Yes
mikeryan 7y ago
Design Systems are much like Frameworks you can either formalize and document the process or not but all this type of information has to live somewhere and be communicated. The hard part here is that now with the rise of alternative tooling like Sketch, Zeplin, Figma and technologies like styled components, SASS, post css etc - there's a pretty broad range of ways to pull all this together so some of the implementation is going to be organization specific. In general though we've found that developing design systems can greatly increase our throughput on new initiatives without having to reinvent the wheel on a lot of basics. There's some overhead but at least it makes for a transparent way to manage communication of a design. Of note there's a great site https://designsystemsrepo.com/ https://designsystemsrepo.com/ that is a repo of a bunch of design systems. Great place to peruse.
- tenaciousDaniel 7y ago
  When I look at design systems, it definitely seems like a good idea. But then when I take a step back and ask myself "what problem are we trying to solve?" my answer is: we need to communicate the intent, behavior, and visual attributes of an application to (a) stakeholders for approval, and (b) developers for implementation. This communication is expected to update over time and potentially to several teams, though not all teams at once since they need to update their own designs in response. When I think about ^THAT problem, I ask myself "is what I'm seeing in a design system the thing that Once And For All solves that problem?", the answer is no. There's something that doesn't feel sustainable to me.
RickS 7y ago
I work on Spectrum, Adobe's design systems team. >extremely difficult to maintain Often yes. This corner of the industry is in the wild west days, and we've yet to establish best practices for a lot of things. Most DS teams are writing custom tooling. It helps a lot, but there are growing pains as we figure out which knobs need twisting and how to automate twisting them. > All design systems I see are art directed. To a degree. We make a LOT of compromises in the interest of maintainability and using visuals and abstractions that generalize well across platforms. Naming conventions, interaction styles etc are often chosen on the basis of being feasible on many platforms, even though that means foregoing some of the flasher stuff might only be appropriate on, say, iOS. Adobe specifically has a particularly heavy burden here, since we have so many properties spanning platforms from the last 3 decades. We could be a lot more adventurous if we had a smaller device footprint. Accessibility is another big concern for us. Contrast ratios, text sizes, etc. Lots of the trendy low-contrast design practices don't fly in our system, and that's intentional. >handcrafted vs generated In Spectrum's case, the design documentation [1] (guidelines on usage, etc) do have custom content, though it adheres to a template and is inside a CMS that allows both editing by non technical contributors (content strategists, designers) and by script (markdown, etc). We have to strike a balance between optimizing for maintenance (autogen everything) and optimizing for content quality (expressive contribution from people that don't necessarily think of content in terms of automated maintenance). Much of our "real" content is maintained in much more automated ways. The UI kits, for example, are generated from a JS + SVG lib that consumes our design tokens (variables for properties in the system across themes, platforms, languages, etc). > is this versioned Yes. It was an ordeal, but it was important and I'm glad we did it. Components are individually versioned and have a changelog. One of the main things we're versioning is more a snapshot of intent, and less a single specific code asset. Let's say button is version 5.0.0. Other parts of the system, like the CSS and react implementations, are independently versioned and track the design system version. This sounds messier than it is, though it's definitely imperfect. > what happens if it's updated? How should the changes at this stage propagate down to the individual teams who consume this design system? we update assets like the guidelines and UI kits on an as-needed basis. Some of this is automated. Some things, like our "don't" examples are created by hand, since definitionally the system doesn't do them. Some changes (bugfixes, implementation refactors, etc) don't require that the design artifacts change. Our downstream customers (and the team itself) consume our data via a package of design tokens, which are issued as JSON. We update these values in accordance with changes to the guidelines, and those changes propagate to our customers and to our automated tools like the UI kit generator. > long term sustainability We're on year 4 or 5 here, and it keeps getting easier as we get better at it. Keeping the design tokens API fairly stable and extending support for previous versions where possible have been big factors in our long term success. While we aim to make update costs as cheap as possible, we also try not to pull the rug out beneath product teams that have slower release cycles and who are bought into previous versions of the system. Happy to answer other questions. [1] random docs example: https://spectrum.adobe.com/page/button/ https://spectrum.adobe.com/page/button/

crtlaltdel 7y ago

If you look at the code in the repo, each component has comments (jsdoc?) which are parsed and rendered as part of the storybook: https://github.com/flexport/latitude/blob/master/Text.jsx#L66 https://github.com/flexport/latitude/blob/master/Text.jsx#L6... https://www.flexport.com/design/components/Text https://www.flexport.com/design/components/Text

mindcrime 7y ago

I'm intrigued by the possibility of using one of these design systems in some of my own work, but I'm likewise concerned about what it means for the long-term. Especially given that I'm not really a UI person first and foremost, I worry about an excessive degree of lock-in that will be hard to back out later if needed. I haven't tried this one yet, but I'm playing around with the IBM Carbon Design System now for an internal side-project thing... depending on how that goes, I might start using that more widely. On that note, I'd be really curious to hear from anybody who has used Carbon, and is willing to share their thoughts, pro or con.

RickS 7y ago
I haven't used carbon as an engineer, but as someone working on design systems, they're overall pretty impressive. For a giant menu of options, see here: https://github.com/alexpate/awesome-design-systems https://github.com/alexpate/awesome-design-systems Atlassian, Lightning, Blueprint, and Polaris are some big names that could be worth checking out. And of course there's always bootstrap. > I'm not really a UI person first and foremost Using another company's component library can be a really fantastic head start, then. Especially if you've got a smaller application that doesn't require the whole kitchen sink. You can build fast with stuff that works, and if down the line you want replace it with in-house components, you've already got a north star of sorts. >I worry about an excessive degree of lock-in that will be hard to back out later if needed. It depends. If you clone the repo and it works for you, you may not necessarily have to keep it updated if you don't want to. I would worry more about being bound to abstractions that are needlessly complex – many of these systems are designed so that small changes to upstream values propagate throughout the system in very deliberate ways, which can make tweaking intermediate values a bit of a landmine. Using a big ass codebase for a couple components means you might have to go spelunking in a big ass codebase.
- mindcrime 7y ago
  Righteous! Thanks for the info.

dmnd 7y ago

Latitude isn't versioned. Flexport's internal monorepo tracks Latitude's master branch. When we make breaking changes to Latitude, we update all internal call sites too. For example, see https://github.com/flexport/latitude/pull/61 https://github.com/flexport/latitude/pull/61 where we replaced our tooltip implementation. This approach has worked well for about 4 years so far. As for docs, we do generate what we can (as explained by my sibling comment). But some pages (e.g. guidelines) are indeed hand-crafted.

mikeryan 7y ago
By updating the tool tip Does the new component propagate out to all sites?
- dmnd 7y ago
  Yes

mikeryan 7y ago

Design Systems are much like Frameworks you can either formalize and document the process or not but all this type of information has to live somewhere and be communicated. The hard part here is that now with the rise of alternative tooling like Sketch, Zeplin, Figma and technologies like styled components, SASS, post css etc - there's a pretty broad range of ways to pull all this together so some of the implementation is going to be organization specific. In general though we've found that developing design systems can greatly increase our throughput on new initiatives without having to reinvent the wheel on a lot of basics. There's some overhead but at least it makes for a transparent way to manage communication of a design. Of note there's a great site https://designsystemsrepo.com/ https://designsystemsrepo.com/ that is a repo of a bunch of design systems. Great place to peruse.

tenaciousDaniel 7y ago
When I look at design systems, it definitely seems like a good idea. But then when I take a step back and ask myself "what problem are we trying to solve?" my answer is: we need to communicate the intent, behavior, and visual attributes of an application to (a) stakeholders for approval, and (b) developers for implementation. This communication is expected to update over time and potentially to several teams, though not all teams at once since they need to update their own designs in response. When I think about ^THAT problem, I ask myself "is what I'm seeing in a design system the thing that Once And For All solves that problem?", the answer is no. There's something that doesn't feel sustainable to me.

RickS 7y ago

I work on Spectrum, Adobe's design systems team. >extremely difficult to maintain Often yes. This corner of the industry is in the wild west days, and we've yet to establish best practices for a lot of things. Most DS teams are writing custom tooling. It helps a lot, but there are growing pains as we figure out which knobs need twisting and how to automate twisting them. > All design systems I see are art directed. To a degree. We make a LOT of compromises in the interest of maintainability and using visuals and abstractions that generalize well across platforms. Naming conventions, interaction styles etc are often chosen on the basis of being feasible on many platforms, even though that means foregoing some of the flasher stuff might only be appropriate on, say, iOS. Adobe specifically has a particularly heavy burden here, since we have so many properties spanning platforms from the last 3 decades. We could be a lot more adventurous if we had a smaller device footprint. Accessibility is another big concern for us. Contrast ratios, text sizes, etc. Lots of the trendy low-contrast design practices don't fly in our system, and that's intentional. >handcrafted vs generated In Spectrum's case, the design documentation [1] (guidelines on usage, etc) do have custom content, though it adheres to a template and is inside a CMS that allows both editing by non technical contributors (content strategists, designers) and by script (markdown, etc). We have to strike a balance between optimizing for maintenance (autogen everything) and optimizing for content quality (expressive contribution from people that don't necessarily think of content in terms of automated maintenance). Much of our "real" content is maintained in much more automated ways. The UI kits, for example, are generated from a JS + SVG lib that consumes our design tokens (variables for properties in the system across themes, platforms, languages, etc). > is this versioned Yes. It was an ordeal, but it was important and I'm glad we did it. Components are individually versioned and have a changelog. One of the main things we're versioning is more a snapshot of intent, and less a single specific code asset. Let's say button is version 5.0.0. Other parts of the system, like the CSS and react implementations, are independently versioned and track the design system version. This sounds messier than it is, though it's definitely imperfect. > what happens if it's updated? How should the changes at this stage propagate down to the individual teams who consume this design system? we update assets like the guidelines and UI kits on an as-needed basis. Some of this is automated. Some things, like our "don't" examples are created by hand, since definitionally the system doesn't do them. Some changes (bugfixes, implementation refactors, etc) don't require that the design artifacts change. Our downstream customers (and the team itself) consume our data via a package of design tokens, which are issued as JSON. We update these values in accordance with changes to the guidelines, and those changes propagate to our customers and to our automated tools like the UI kit generator. > long term sustainability We're on year 4 or 5 here, and it keeps getting easier as we get better at it. Keeping the design tokens API fairly stable and extending support for previous versions where possible have been big factors in our long term success. While we aim to make update costs as cheap as possible, we also try not to pull the rug out beneath product teams that have slower release cycles and who are bought into previous versions of the system. Happy to answer other questions. [1] random docs example: https://spectrum.adobe.com/page/button/ https://spectrum.adobe.com/page/button/