You can think of flying to Mars like one of those art films where the director has to shoot the movie in a single take. Even if no scene is especially challenging, the requirement that everything go right sequentially, with no way to pause or reshoot, means that even small risks become unacceptable in the aggregate.
Strong Deb Chachra vibes in this ongoing series by Charles C. Mann:
he great European cathedrals were built over generations by thousands of people and sustained entire communities. Similarly, the electric grid, the public-water supply, the food-distribution network, and the public-health system took the collective labor of thousands of people over many decades. They are the cathedrals of our secular era. They are high among the great accomplishments of our civilization. But they don’t inspire bestselling novels or blockbuster films. No poets celebrate the sewage treatment plants that prevent them from dying of dysentery. Like almost everyone else, they rarely note the existence of the systems around them, let alone understand how they work.
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?
Interesting—this is exactly the same framing I used to talk about design systems a few years ago.
CSS wants you to build a system with it. It wants styles to build up, not flatten down.
Truth!
Debating complexity is pointless because it’s a subjective metric. Every developer has a different gut feeling about simplicity, complexity and the appropriate amount of complexity for a given task. When people try to find an objective definition, they come to wildly different results. And that’s okay.
Instead, we should focus on hard metrics from a user perspective. Performance, efficiency, compatibility, accessibility and fault-tolerance can be measured, tested and evaluated, automatically and manually.
Any amount of complexity is fine as long as these goals are met.
- People only understand things relative to things they already understand
- People only understand things in context
- People rely on patterns and consistency
- People seek to minimize cognitive load
- People have varying levels of expertise and familiarity
- People are goal-oriented
- People often don’t know what they’re looking for
- Information is more useful when it’s actionable
This is kind of about art direction and kind of about design systems.
There is beauty in trying to express something specific; there is beauty too in finding compromises to create something epic and collective.
My only concern is whether we are considering the question at all.
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.
Call it HTMLX or call it Hijax, what matters isn’t the code so much as the idea:
Front-end JavaScript fatigue is real. I’m guilty myself of over-engineering JS UI despite preferring good old server templates. I don’t even think HTMX is that good but the philosophy behind it embarrasses the modern JavaScript developer. For that I appreciate it very much.
Snook’s Law in action:
Big, flashy things get noticed. Quiet, boring things don’t.
There isn’t much infrastructure in place to quantify the constant, silent, boring, predictable, round-the-clock passive successes of this aspect of design systems after the initial effort is complete.
A lack of bug reports, accessibility issues, design tweaks, etc. are all objectively great, but there are no easy datapoints you can measure here.
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.
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.
“Make the logo bi… exactly the same size.”
You know when a new boss takes over a company and the first thing they do is declare an immediate rebranding? It turns out that the monarchy has been doing that for generations.
I hereby dub this Snook’s Law:
Any working system can become invisible to the point where the system loses value because it’s working.
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?
A delightful ode to a once-divisive design.
A terrific piece from Aaron Sankin that goes from Waldsterben to software development via firefighting and the RAND corporation.
Bureaucracies use measurements to optimize and rearrange the world around them. For those measurements to be effective, they have to be conducted in units as relevant as possible to the conditions on the ground.