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.
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.
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.
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.
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.
For a giant menu of options, see here: 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.
>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  (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.
 random docs example: https://spectrum.adobe.com/page/button/
One of the things I observe that's potentially good for smaller players and less exciting to a team like mine is that ~80% of the market is web/react only, and very satisfied with things that are 1) narrowly scoped in terms of platform coverage 2) mostly about "stickers" or pictures of design, even as more advanced players are itching to design with more dynamic, deeply integrated component representations.
I'm curious about your thoughts on what it means to "nail it" with a full-scope / all-inclusive solution to design systems problems. Currently, I think that an ecosystem of smaller, more tightly scoped tools is the likely path forward. Designers will be plumbing together pipelines of modules that fit their specific needs, the same way a react project would today. I did a thread on this you might be interested in .
Feel free to ask whatever – anything I can say is fair game, and anything I can't say I wouldn't have said anyway.
As it happens, I am working directly in one of those areas you mentioned. I'm trying to create a nicely abstracted language that designers can use to describe components from a platform-agnostic angle. Something more nuanced and sophisticated than "pictures of design", but something that doesn't leak implementation details. A shared language that teams of designers can use to communicate not just with themselves, but also developers.
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.
I'm working on a design system at the moment and I have looked at a few for ideas.
A nitpick concerning slow animations: there is no place for them in a modern enterprise app.
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?
One thing about inline-editable components and tables. As a former office drone and a part-time speditioner, I believe that such components must be tabbable, and an ideal editable table should try to mimic the desktop experience. Office workers spend thousands of hours in backoffice apps, watching 0.3s animations and aiming with a cursor, but they never complain because they don't know any better.
Just to demonstrate a different InlineEdit, here is a demo of a lib I made several years ago. It worked great with tables and card views: https://kaivi.github.io/riek/
Also didn't your former colleague write up this post on data tables in 2017? It was trending here yesterday. Looks like a lot was already implemented back then: https://uxdesign.cc/design-better-data-tables-4ecc99d23356
EDIT: my bad, INTERNALS is just a FB thing, I've just never noticed
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.
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)
Components should be provided by browser/OS vendors with a standard look and feel, the same way desktop software has been written for decades. React Native is a glimpse of what HTML of the future will look like.
Flexport is a logistics company. They aren’t in the business of selling software.
What we’re doing right now is like the first GUI desktop apps - lacking consistency because there was no solid platform every designer reinvented the wheel.
“Websites” is this general term that is hard to define these days. Sure a landing page for a restaurant should have its own design, just as business cards do. But an application like Gmail? Probably not the same thing.