Design systems: Our house
Like most things that are difficult to explain, folks that work with design systems use metaphors to help discuss system related concepts.
Lego pieces, design artifacts, UI pieces…
What these examples miss is an opportunity to discuss the relationships of the various pieces that make up a design system. Relationships matter in systems since they can affect different outcomes and help us craft different experiences–even when building from the same pieces.
Which is why I’ve settled on a new metaphor: Design systems–our house.
📫 What’s my address?
At a basic understanding, houses determine where, how, and why we live in certain ways and styles.
Is our house located in the desert near the equator or up high in some Northern mountains? Can we assume that our houses get default features like air conditioning or a fireplace driven by these warmer or cooler climates? Are we in an urban or rural environment? Could that influence a larger or smaller square footage for our dwelling?
Bringing our metaphor to a business sense, we can imagine that understanding a company, its purpose, and available resources matter for where, why and how we create design systems. It helps answer questions like: Is my system meant to be used on the web, within an operating system, or across hardware? Will this be a grassroots effort across functions or will I have the funding for a dedicated team to help build out the system? What kind of artifacts will we build and how do we prioritize them?
We can answer so much around the structure of a system and how we might work on it by focusing on the where, why, and how first.
🔑 My house, your house
Imagine if you lived in a newly constructed suburb where each house were crafted from a same footprint. We rely on visual markers to help distinguish between them: Address numbers, paint, landscape, and interior all matter to create a unique expression of identity from one house from another.
Similarly, design systems that support multiple brands do not necessarily create unique individual systems in isolation but rather define a set of flexible tokens that map to a theme which can therefore leverage the same underlying UI. One of my favorite examples comes from the Stitch Design System which supports 7 of Gap’s major brands.
🚪Step inside
Houses are constructed of various rooms which have purpose and intention. Sometimes it’s obvious what we can and can not do in these rooms and sometimes it’s flexible.
Nothing is stopping you from sleeping in your living room. A couch as a bed can satisfy the basic functional place to sleep and we keep living our lives. But we miss all the benefits that a dedicated bedroom can provide us: the privacy when we close the door, the comfort of a made bed, and the consideration that the living space may now be used for other meaningful purposes. (Watching TV, lounging, hosting guests, etc)
A more obvious example on room intention can be generally understood through why we don’t find toilets in kitchens. Need I go into the obvious health and safety concerns with this wild concept?
I love talking about these examples because it highlights when a system should and should not flex — A tricky part of systems discussions which often get mistranslated to “rules”.
I’m not going to stop a designer from mocking up a new in-line alert for a form invalidation experience. Instead, I’m going to learn what they’re trying to design for. I might take an opportunity to discuss the purpose of alerts and why we think they’re important for other sets of user experiences. I might even inform the designer how our form UI already have built in error text. These two points might satisfy the problem at hand and therefore I’ve successfully guided the designer to adhere to the system rather than construct new one-off designs.
But I also might learn something new from the proposed design and identify a valid use-case that the system does not support. We might ingest some of the design into our existing components and APIs. We might further refine our supporting documentation on usage. This is a good example of the system flexing with the needs of its customers.
Foundational design decisions, often found in our tokens, are more difficult to dispute or flex. Once we determine our brand colors, I generally encourage system users to adhere to its correct usage. We do not allow values outside of what we’ve defined for our experiences.
No toilets in the kitchen, please.
🏘️ Conclusion
This house metaphor can keep on, keeping on. It’s a great framework to use when holding different conversations about design systems. I keep finding small insights and tidbits which further support the complex nature of how systems work with various functions, roles, and relationships.
What’s your go-to design systems metaphor?
