There’s a lot of “same-ness” across design systems. Yesenia Perez-Cruz said it well:
Sameness over cohesion. This is probably the biggest issue I’ve seen with design systems. They can lead to a feeling of visually generic sameness instead of a feeling of cohesion across an experience.
We’re all subtly influenced by the zeitgeist of the day but —in my experience— a lot of the look and feel of components in a design system get born out of a fear of variable content. On my first big design system project I remember someone telling me, “This component has to be able to exist in any context” and I felt the weight of the universe pressing on my shoulders. All those contexts and content shapes a component can exist impact the final product.
Take the humble Card component. Quick riffing, here’s a short list of the content features and states it needs to support in a decently mature product:
| Prop | Status |
|---|---|
| title | on |
| title_size | small/medium/large |
| title_length | short/medium/long/too long |
| title_truncation | on/off |
| description | on/off |
| description_length | short/medium/long/too long |
| description_truncation | on/off |
| image | on/off |
| image_shape | portrait/landscape/square/circle |
| buttons | none/one/two |
| button_icon | on/off |
| card_layout | vertical/horizontal |
| card_padding | small/medium/large |
| card_border | on/off |
| card_is_link | on/off |
| language_dir | ltr/rtl |
| theme | light/dark |
This component must be defensively designed and built against any permutation of author-supplied content. What was once a humble visual display component is now a content workhorse. Any component has the potential to become a little machine filled with a myriad of rules and requirements. There’s gravity towards becoming a multi-use component.
In Storybook and Figma these lil’ state machines manifest as knobs and dropdowns. Knobs provide an interface for the large underlying feature matrices of properties, showing the programmable pieces allowing experimenters to flip them on and off or change properties at will. These if-statements have a cost as each component swells with atomic business logic. If you’re lucky, someone is keeping track of these intents in a test suite, otherwise it will be even harder to change later.
It’s not just logic that informs components. Components also adhere to compliance standards like legal approval, internationalization, accessibility audits, and have other social contracts (e.g. “the boss doesn’t like blue”) baked into their history and design. I’m building a tool to collect component histories, constraints, and insights, but quick and radical changes are always harder in a complex system. It’s tough to “be funky” in the confines of a strict system.
All these complexities dilute the component towards a bland defensive design, averaging itself against every possible permutation of content. As utility goes up, so does boringness in a design system. And that can be a good thing! In the same way NASA doesn’t want bespoke iconography on their spacecrafts, your users want some visual and aural consistency when traversing a content network or application. Understanding this tension in design systems is important.
In future posts I’ll look at how to spot opportunities for breaking out of boringness with a design system.