Design systems: be specific about your generalities.
Beyond promoting consistency, a design system is also a facilitator of change.
It’s originally an artist’s trick, not a designer’s one: When painting from observation, look at your object while you close one eye and squint the other:
The composition you are drawing is being reduced to a mere silhouette, lacking most of its details, yet completely recognizable by its essence.
We block this germinal form accurately on our paper or canvas. Once we get it right, the rest of the painting is just negotiating the details.
Design Systems work is sometimes a bit like that, only that we squint through time instead of space: The further we look down the product roadmap, the more abstract what we see, but at the same time also easier to distinguish the strategic essence of our plan from its blurry details.
When we keep things too general, we fall short of supporting our product teams’ current needs. But when we get too specific, we fail to support their future ability to change and adapt as they grow and scale.
A product’s present holds both its past and future
Product design is a continuous movement: We know where we are, we know where we want to be, and we have a hypothesis-based plan for how to get there, which we test and validate as we move forward.
Over a product lifetime, every version we develop relates to a certain previous solution (by either continuing or disrupting it) and sets the ground for a range of possible futures down the road.
As knowledge is continuously gained and each milestone gradually takes shape, the design system's role goes beyond just speeding development with reusable components: It is to provide a general, yet solid design consensus, so products can shift and pivot easily within it. It enables change by defining the channels of consistency.
Just as the design system supports products present with specifications, supporting the product’s future means supporting a certain level of abstraction.
Abstraction and Generalization:
I have just mentioned abstraction and generalization, and It's important to take a minute to tell those two concepts apart:
Abstraction aims at simplifying the description of an entity, while generalization looks for common properties among several abstractions.
Abstraction is needed in product development
I identify Abstraction in the product context, more or less by the classic scheme of Jesse James Garrett’s Elements of User Experience:
When considering process over time, these levels also function as the degree to which we limit the details of our solution and their pace of change, to separate the parts based on what we already know from those based on what is still there to discover or validate.
Generalization is needed for abstraction:
By Generalizations I refer to the more conceptual areas of the design system, as supporters of the product: The common patterns, principles, and properties at the heart of the deliverables, shared across its supported products.
The more distant in future and abstract the product milestone is, the more unknowns lie ahead of it, and the more general the design system support for it can be. This generality also needs to be defined: This is where the Design System Foundation level comes in.
A Foundation level should be opinionated
Besides providing the visual design essential, the Foundation level is the design system’s conceptual base, and it defines the product’s relationship with the brand. It may cover aspects such as Accessibility, Color palette, Typography, Iconography, and hopefully a set of Design Tokens, but an effective foundation will also be opinionated about the essence that brings them together.
Be it brand strategy, content policy, code philosophy, information architecture, or any other domain that is navigating the product’s growth under the brand, every design system is driven by different goals.
Apple prioritizes the considerations of the specific platform you design for to the rest of its foundations. Shopify Polaris Design System promotes content formation and information architecture to the rest of the considerations.
How high strategy finds its way downstream in a design system can take many directions, but a cool example can be the layered abstraction pattern introduced by Charlie Backus at #Spotify.
When trying to tell a design system’s purpose, I often distinguish design system motivation as either being led by the brand or by the product:
a Brand-led design system:
If a design system’s goal is supporting many- and rather different- products under a single, overarching brand identity, it might be based on brand values and visual guidelines, keeping a rather general approach, allowing all products (or even product tiers) the needed differentiation range under its umbrella.
a Product (offering)-led design system:
If the goal is to set a unified infrastructure to support the development of a rather organically connected product offering, the design system might be based on Information Architecture and driven by the shared concepts and semantics, enabling scale around essence and letting visual concepts emerge from within and differentiate.
The thing is, that patterns and elements in a design system carry meaning within the product context. They will suggest an expected user behavior, echo a brand value, convey a certain hierarchical order, or a semantic connection between data elements.
The areas we leave clear for each product to differ shape the meaning and are just as important.
This meaning is often derived from a general essence, and Knowingingly defining it can guide countless of debates along the process.
a “System of systems” future:
Defining the long-range essence of a design system, beyond being a components and design-tokens supply, is becoming more vital:
At the time I write this, the future of design systems seems to be heading toward the concept of a “System of systems”, whether through top-down standardization or bottom-up AI-fueled personalization.
Component implementations will be far more related to context, and consistency will depend much more on concepts and ideas rather than component visibility. The unique meaning of those concepts and ideas will need to be understood by both machines and humans.
Generalization and the pace of change:
In his recent article, “Ship faster by building design systems slower” Designer Josh Clark introduces the concept of pace layers within a product environment. He points out that each layer in the product development cycle changes slower than the layers on top of it.
A Design system will update slower than the products that it supports, not in parallel: It will provide existing components to support a current development effort, The product team will make their adjustments, if needed, outside the design system’s scope, which in time, once validated, will be either standardized into the design system or exempted as a “unique snowflake”.
In terms of a product design process, a design system is “The Island of the Day Before”: an agreed consensus of the previous product state, ready to be reused for present needs.
This is true within the design system as well, as each element draws stability from the more general layer it’s based upon, and changes faster: Components draw from patterns, which draw from design principles, and so on, but each design system has its own logic flow between those layers.
When a design system builds a good conceptual foundation,
a few things happen:
The Design system becomes a source of influence rather than control.
No more patterns police. Product teams are given space to lead their interpretations within their context. Consistency is based on ideas before it is based on pixels.
Product teams are more involved, engaged, and creatively free.
It turns product teams from subscribers waiting for your components
to active brains working out solutions with you, some of them you would never have thought of yourself.
The Design system is easier to adopt.
Since products gradually share the concepts the design system is based on, before implementing a single component. Yes, Design systems are also for products that did not adopt them.
The Design system maintains a thinner component library,
of more quality components.
because a better-understood system can rely more on each team's interpretation and requires fewer out-of-the-box case-oriented solutions.
The Design system can support tokenizing of a wider range and more abstract attributes, once we have a clear general context around them.
From a design system perspective, supporting product scale and growth means providing product teams with design purpose and concepts that draw a vector, rather than just assets that support products' needs. They should be specific enough to guide development from abstract to concrete state over time, and general enough to allow products the space for pivoting and experimentation, through discovery and change.
It requires us to give up control in favor of influence and own things through logic and purpose rather than guidelines and components.
Let us be very general about the specific,
and very specific about the general.