This is an interesting comparison: design systems as APIs. It makes sense. A design system—like an API—is a contract. Also, an API without documentation is of little use …much like a design system without documentation.
Chris describes exactly why I wrote about toast:
But we should be extra watchful about stuff like this. If any browser goes rogue and just starts shipping stuff, web standards is over. Life for devs gets a lot harder and the web gets a lot worse. The stakes are high. And it’s not going to happen overnight, it’s going to happen with little tiny things like this. Keep that blue beanie on.
Every UI control you roll yourself is a liability. You have to design it, test it, ship it, document it, debug it, maintain it — the list goes on.
It makes you wonder why we insist on rolling (or styling) our own common UI controls so often. Perhaps we’d be better off asking: What are the fewest amount of components we have to build to deliver value to our users?
Robin describes his experience of using a design system, having previously been one of the people making and enforcing a design system:
However it’s only now as a product designer that I realize just how much I want the design system to carefully guide me instead of brute-forcing its decisions onto my work. I want to fall into the loving embrace of the system because I don’t wanna have to think about hex values or button sizes or box shadows. I don’t want to rethink padding and margins or rethink the grid each time I design a page.
But by golly if a design system says “no” to me then I will do my very best to blow it up.
Every day, a new marketing email, Medium post, or VC who will leave Twitter when they’re cold in a body bag tells us that machine learning (ML, which they call AI because it sounds more expensive) is going to change the way we work. Doesn’t really matter what your job is. ML is going to read, write, code, and paint for us.
Naturally, the excitement around ML has found its way into the design systems community. There’s an apparent natural synergy between ML and design systems. Design systems practitioners are tantalized by the promise of even greater efficiency and scale. We wish a machine would write our docs for us.
We are all, every single one of us, huge fucking nerds.
Call me Cassandra:
The way that industry incorporates design systems is basically a misappropriation, or abuse at worst. It is not just me who is seeing the problem with ongoing industrialization in design. Even Brad Frost, the inventor of atomic design, is expressing similar concerns. In the words of Jeremy Keith:
[…] Design systems take their place in a long history of dehumanising approaches to manufacturing like Taylorism. The priorities of “scientific management” are the same as those of design systems—increasing efficiency and enforcing consistency.
So no. It is not just you. We all feel it. This quote is from 2020, by the way. What was then a prediction has since become a reality.
This grim assessment is well worth a read. It rings very true.
What could have become Design Systemics, in which we applied systems theory, cybernetics, and constructivism to the process and practice of design, is now instead being reduced to component libraries. As a designer, I find this utter nonsense. Everyone who has even just witnessed a design process in action knows that the deliverable is merely a documenting artifact of the process and does not constitute it at all. But for companies, the “output” is all that matters, because it can be measured; it appeals to the industrialized process because it scales. Once a component is designed, it can be reused, configured, and composed to produce “free” iterations without having to consult a designer. The cost was reduced while the output was maximized. Goal achieved!
Jeremy is not eating toast.
From pattern portfolios to Fractal.
Gotta keep ‘em separated.
A presentation at An Event Apart Boston 2018.
You should hire Clearleft for these front-end development skills.