Whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”
HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes up: everything has one job, does it really well (ideally), which makes the possible options almost infinite.
Design systems should hope for the same.
Lovely photos by Marc from Patterns Day!
Trys threads the themes of Patterns Day together:
Jeremy did a top job of combining big picture and nitty-gritty talks into the packed schedule.
A nice write-up of Patterns Day from Hidde.
Okay, if you weren’t already excited for Patterns Day, get a load of what Rich is going to be talking about!
You’ve got your ticket, right?
In some ways, the fervor around AI is reminiscent of blockchain hype, which has steadily cooled since its 2021 peak. In almost all cases, blockchain technology serves no purpose but to make software slower, more difficult to fix, and a bigger target for scammers. AI isn’t nearly as frivolous—it has several novel use cases—but many are rightly wary of the resemblance. And there are concerns to be had; AI bears the deceptive appearance of a free lunch and, predictably, has non-obvious downsides that some founders and VCs will insist on learning the hard way.
This is a good level-headed overview of how generative language model tools work.
If something can be reduced to patterns, however elaborate they may be, AI can probably mimic it. That’s what AI does. That’s the whole story.
There’s very practical advice on deciding where and when these tools make sense:
The sweet spot for AI is a context where its choices are limited, transparent, and safe. We should be giving it an API, not an output box.
User research into deceptive design patterns:
Despite our technological advancement and understanding of human nature, it’s still common to see deception in digital products. To understand digital deception (and better define it), we surveyed 536 people to measure and discuss people’s understanding of this matter.
Here’s an aggregator of components from multiple design systems.
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!
Design systems as codified constraints.
A library of UX components is one common part of a design system, but the system itself is something bigger. A good system is also a shared set of strategies for solving visual and interactive communication challenges, a playbook rather than a script.
I like this way of putting it:
The problem is that treating a design system as a pantry full of widgets is, in and of itself, a failure of both craft and imagination. Think of it like a language: if a writer’s only engagement with it is grabbing words from the dictionary and heaping them together until “message” is achieved, things are going to suck. Language is more than a bag of words.
A beautiful meditation on Christopher Alexander by Claire L. Evans.
A collection of design patterns and principles for mitigating the presence and spread of online hate and harassment in social platforms.
I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.
Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:
Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.
This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:
If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.
This is a terrific resource! A pattern library of interactive components: tabs, switches, dialogs, carousels …all the usual suspects.
Each component has an example implementation along with advice and a checklist for ensuring its accessible.
It’s so great to have these all gathered together in one place!
We noticed a trend: students who pick a UI framework like Bootstrap or Material UI get off the ground quickly and make rapid progress in the first few days. But as time goes on, they get bogged down. The daylight grows between what they need, and what the component library provides. And they wind up spending so much time trying to bend the components into the right shape.
I remember one student spent a whole afternoon trying to modify the masthead from a CSS framework to support their navigation. In the end, they decided to scrap the third-party component, and they built an alternative themselves in 10 minutes.
This tracks with my experience. These kinds of frameworks don’t save time; they defer it.
The one situation where that works well, as Josh also points out, is prototyping.
If the goal is to quickly get something up and running, and you don’t need the UI to be 100% professional, I do think it can be a bit of a time-saver to quickly drop in a bunch of third-party components.
I only just found this article about those “mad libs” style forms that I started with Huffduffer.
I completely agree with Dan that when it comes to design systems, completeness is an over-rated—and even counter-productive—goal:
Some organizations seem to hold up the ideal that, once a design system exists, everything in an interface can and should be built with it. Not only is that an unrealistic goal for most enterprises, but it can often be a toxic mindset that anything less than 100% coverage is misuse of a design system at best or utter failure at worst.
I remember Lara telling me a great quote from the Clarity conference a few years back: “A design system needs to be correct before it’s complete.” In other words, it’s better to have one realistic component that’s actually in production than to have a pattern library full of beautiful but unimplemented components. I feel like Robin is getting at much the same point here, but he frames it in terms of correctness and usefulness:
If we want to be correct, okay, let’s have components of everything and an enormous Figma library of stuff we need to maintain. But if we want to be useful to designers who want to get an understanding of the system, let’s be brief.
It’s great to see former Clearlefties like Nat, Paul and Anna rightly getting namechecked in this history of designing for the web in a systemic way. It’s a tradition that continues to this day with projects like Utopia.