The Negative Space of Design Systems
a Design System is also about the products that don’t adopt it.
In real life, most products are not fully aligned with their brand’s design system at any given time. Either due to natural growth or foundational gaps, The customer experience of a brand includes both the products and features that adopted the design system and the ones that haven’t.
Design systems need to be planned in a way that not only promotes consistency but also acknowledges strategic gaps between the brand’s products.
Consistencies and differentiations
Even within the same brand or offering, each product has its own unique perspective and way of doing things.
This uniqueness, either planned or incidental (think of teams that worked in silos, acquisition of a mature product by an external brand, etc.), is often the very core of that product’s value proposition, and can’t be compromised for the sake of cross-product consistency.
In this aspect, the flip side of a Design system’s role as an agent of consistency is also to serve as a facilitator of difference.
If consistency is applied through the design system artifacts (#designtokens, #patterns, #components, etc.), differences are about the areas for which the design system either creates the right distinctions or stays clear and knowingly leaves each product the space to optimize things for its own.
Especially in the early days of a design system, when conventions are often being set on the go, what we choose not to include or document is just as important as what we do.
The early-adoption bias
As Ben Callahan indicates in his Design System Maturity Model, once v.1.0.0 of a design system is being shipped, its team focus of attention shifts from building the thing to growing adoption.
In this phase, the design system team is looking for validation: quick wins, fast (and safe) failures, and a gradual build of trust.
This means that although the pilot adopters will probably not be the brand’s most strategic features or products, they might, potentially, have a stronger impact than later more important ones- on its design system conventions and point of view.
When different products use a limited set of reusable patterns to solve different user needs, those patterns will often suggest different meanings and conceptual models within one product and another.
Mental and Conceptual models
Covering mental and conceptual models properly is beyond the scope of this article. I recommend Alana Brajdic Understanding Mental and Conceptual Models for a short and clear recap and the Indi Young Mental Models book for a deeper dive.
As design system work shifted from its original bottom-up to a top-down approach, we basically traded much of the organic growth that came with Atomic Design in favor of governance and more manageable scalability.
This makes design systems often take structure and principles earlier in the process, and not always in-pace with their actual adoption.
It’s important because when we adopt system patterns or elements, we also adopt the wider mental model they invoke in users.
We tell users what our conventions are, where to look for staff, and how things are being done, and those might be different between one product and another, even when they appear to be similar.
To make things harder, since a big factor for including a pattern or component in the design system is reusability, the very concept of a design system, in a way, encourages us to ignore conceptual differences that are rather significant in the product’s information architecture, as long as we can provide it a good-enough UI solution within our existing library.
Conceptual model differences might be:
- Moving from a centralized to a decentralized service environment
when shifting from Twitter to Mastodon. - Different Branching models in different Version Control mechanisms such as Git and Mercurial
- Different ways to perform a job: Affinity Designer does the same jobs as Adobe Illustrator, through an entirely different process and architecture (Assets export is a good example).
- A similar way to perform different jobs: Applying the Search pattern by OpenAI for ChatGPT for prompting AI-generated content, using a familiar mental model to base a new conceptual one.
- Different scopes of participants: Shared contribution models (Figma) vs private ones (Sketch).
- Using the same component for different purposes: a Card element, meant to represent complex data objects, is used to create layout divisions.
The point is, that no design system will address all the differentiation range of its products in its early phases, but it should be aware of the unsolved gaps and contradictions it attempts to serve, and make sure that the patterns it includes convey the right ideas about the nature of features they support.
It often helps to map in advance both the dominant mental models of our users as well as the main conceptual models driving our brand’s products, on their similarities and differences, as part of our preparation, so we have a clear view of our overall terrain before starting to populate a pattern library with early design-system adoption requirements.
Summary
Beyond the obvious roles of speeding development and bringing continuity to different products of a brand, the very existence of a design system hints at a customer’s value in the seams between its supported and unsupported products, and not only in the products themselves.
The unsupported differences and gaps, as well as the underlying concepts and models that drive them, are a significant part of this promise. It is where the design system stops being a mean of control and start being a source of influence.
