- 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.
A collection of collections, this is a directory of design systems, with the handy option to browse by component type. The blueprints section is still a bit thin on the ground, but likes the most useful bit—an in-depth dissection of individual compenent types.
Josh mashes up design systems and pace layers, like Mark did a few years back. With this mindset, if your product interface are in sync, that’s not good—either your product is moving too slow or your design system is moving too fast.
The job of the design system team is not to innovate, but to curate. The system should provide answers only for settled solutions: the components and patterns that don’t require innovation because they’ve been solved and now standardized. Answers go into the design system when the questions are no longer interesting—proven out in product. The most exciting design systems are boring.
Answers on a postcard, please (and by postcard, I mean textarea).
When you think of heraldry what comes to mind is probably knights in shining armor, damsels in distress, jousting, that sort of thing. Medieval stuff. But I prefer to think of it as one of the earliest design systems.
This totally checks out.
The best reason to write a library in plain JavaScript is that it lasts forever. This is arguably JavaScript’s single most underrated feature. While I’m sure there are some corner cases, JavaScript from 1999 that ran in Netscape Navigator will run unaltered, alongside modern code, in Google Chrome downloaded yesterday. That is true for very few programming environments.
And yet:
Of course, most people’s experience with JavaScript is that it ages like milk. Reopen a node repository after 3 months and you’ll find that your project is mired in a flurry of security warnings, backwards-incompatible library “upgrades,” and a frontend framework whose cultural peak was the exact moment you started the project and is now widely considered tech debt.
Claire L. Evans has written a beautiful piece on the difference between growth and scalability:
Life is nonhierarchical, and it shirks top-down control. But scalability relies on hierarchy, on the isolation of elements stripped of history and context. It is predicated on the assumption that nature is little more than a raw material to be processed and commodified until it is spent. This is, of course, unsustainable — at any scale.