Design System Tiers
Back in January, Brad Frost introduced the concept of a Global Design System, and the idea has spread like wildfire for those of us for whom it resonates resoundingly.
What I heard in that blog post, and in Brad’s voice while attending episode #11 of Ben Callahan’s The Question series, was a frustration rooted in decades of working on the web and seeing the same thing occur time and time again: HTML semantics and a11y best practices taking a back seat to product priorities.
Those of us who understand the craft are duly frustrated. It’s not a dogmatic, pie-in-the-sky unrealistic goal we loft for, but simply ensuring the door opens and closes before we decorate it.
If you want to feel the pain, there is no greater explanation than Stephanie Stimac’s wonderful Standardizing Select talk from Clarity ’21. Her talk is a window into the countless hours engineers spend toiling away either rebuilding or attempting to style native form controls.
This work translates into massive cost for businesses. Nathan Curtis demonstrated associating a monetary value with the reproduction cost associated with just a button. Even things like button size can be debated ad nauseum.
The concept of a global semantic, accessible foundation built with web standard Web Components ignited something in me. It prompted me to go into research mode, and I started stewing on what a “core” set of global components might look like.
For my inputs, I considered some great efforts at close-to-the-metal definitions of segmenting components into separate layers, or tiers, and what could potentiate a “core” set of components vs. the upper layers of, as Brad describes, recipes, et. al. This included:
- Nathan’s “parts” sheet
- Brad’s ecosystem blog post
- my notes from Nathan’s Design System Ops workshop @ Clarity ‘21
- the open-source Lit library Shoelace
- everything documented at component.gallery
As I reviewed the sources, I found it easy to start organizing components into the core/recipe/smart categories defined in Brad’s ecosystem post, but another curious way to categorize the components started to emerge:
- those with explicit HTML counterparts
- those without explicit HTML counterparts, but really well defined semantics and accessibility
- those without explicit HTML counterparts, and fuzzier semantics and accessibility
Everything is in the Figma links below, and I’m by no means suggesting this is a hard definition of things, but rather a starting point for conversations. Given time, the next step I’d likely take is reviewing the component list at Open UI and how that may change my thinking around how I initially organized things.
I hope this resonates with others who enjoy macro-level categorization as much as I do.
