Latitude Design System

https://github.com/flexport/latitude/blob/master/Text.jsx#L6... https://www.flexport.com/design/components/Text

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.

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.

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/ that is a repo of a bunch of design systems. Great place to peruse.

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

I'm working on a design system at the moment and I have looked at a few for ideas.

Some design systems are comprehensive, mature, and general enough that they're suitable for use by hobbyist devs or smaller orgs that want attractive, versatile UI components but don't want to spend effort spinning up something of comparable quality internally. Ant design comes to mind as one I see frequently.

The other benefit is companies that offer extensive third party integrations, like saleforce with their Lightning design system. By making the DS available, they let third parties build plugins that feel like a part of the platform, with high quality tools. This helps negate a lot of common problems with platform plugins that are ugly/unintuitive/broken.

Design system tooling (as opposed to UI component libraries) is more of a traditional open source / giving back dynamic. Theo from Salesforce and Style Dict from Amazon are widely used as part of the infrastructure underlying smaller companies' internal design system efforts, without going so far as to influence specific component implementations or visual styles. It's akin to FB and google opensourcing data infrastructure tooling.

But we were thinking perhaps we should spend some effort making it easier for others to use <Table /> elsewhere. How close to usable is it for your use case?

Two major drivers come to mind in terms of DS adoption:

1) Giving teams a common toolkit of resources so that they can design consistent experiences without having to independently implement and maintain the same components.

2) It's really trendy. It's the designer equivalent of moving to serverless, or nosql years ago, etc etc. Small teams do it because it's cool and fun despite not necessarily feeling the enterprise-scale pains that originated some of the practices.

(I would not put flexport in that category. They've got an extremely data-intensive software, and a good component lib helps a lot there)

But honestly this is just design management starting to make a real improvement to how design works across teams and applications.

There seems to be a lot of push back here towards these systems and I'm not sure why. They just capture a ton of design information that already has to exist into a single place and tooling like React pairs great to break re-usable UI elements into common and shared components.

Design Systems are A Good Thing that's improving what has been a pretty broken system.