The 3 types of design system deviation
Virgil Abloh said that a 3% change to an object could be a new design. Desirable disruption in fashion, less so for your design system's success. Beware of the impact of "minor" deviations.
Virgil Abloh was both praised, and criticized, for his “3% rule” in fashion design. Over-simplified, it was the claim that a design only needs as little as 3% of change to become “new”. One of the most well-regarded designers of the 21st century viewed minor deviations as potentially transformative, or disruptive. Such disruption is a desirable aim in the fashion industry. But it’s probably not the case when it comes to your design system implementation.
“Minor” deviations from design system guidelines or components is a fairly common occurrence. It can be accidental, or deliberate. Done through ignorance, obstruction, or a good faith effort to solve a problem.
Those deviations aren’t minor.
They have knock-on effects. Often outside the context of a single product. And very quickly they can lead to the multiple inconsistencies in a user experience that the design system is supposed to be solving! A hundred small variations in the experience leads to one incoherent, dissonant, whole.
Accidental deviation is the most immediately addressable. It’s most common in the early stages of a design system’s journey to maturity. Guidance, tooling, and code resources are less robust, less comprehensive. Practically, and culturally, people are less familiar with design system usage. Mistakes at the design or development stage are understandable and, usually, correctable.
Design system maturity should organically resolve many of these issues. Clear and robust guidelines on principles, components, and patterns, lead to more familiar, better educated, practitioners. Tooling, such as design kits that accurately mirror code resources, help automate correct implementation. And cultural change that better embeds design system understanding makes compliance a more natural part of the concept-to-delivery process.
Wilful ignorance is tougher to resolve. This is where the design system is overlooked, or trivialized, in importance. Teams use it when they want, don’t when they don’t. They know the design system is there, and it might prove useful to them, but there’s no sense of being beholden to its guidelines. The organic resolution of more innocent implementation errors doesn’t have the same traction.
A more robust approach to build engagement and reinforce guidelines is necessary. Outreach, in the form of education and activation sessions, can directly connect with specific team. A focus on the efficiency argument, with quantitative data, can highlight value to product owners who aren’t prioritizing stricter design system adoption in their product backlog. And this can also be a time to work on a clearer, top-down, executive mandate on design system adoption.
Deliberate deviation is where teams make changes in design, or the code, while they using the design system to build their product. They may believe they know better. Or that there are domain or product specific considerations that need to be addressed. Or they could face a tough delivery calendar where they feel they need to “hack” a solution to be able to ship.
Governance processes become important here. At its simplest, I work on these top-level rules for how teams or business units should engage with the design system.
Greater specificity is OK
e.g. they may decide they will only use the light theme version of the design system, not the dark. Or even limit their component usage to a subset of what’s available.Domain specific technical guidance is OK
In particular, the product level is where information on how to connect business logic should be provided. How will the abstracted front end elements of the design system connect with APIs and underlying architecture?Addition and extension is OK
Do they need a component that isn’t in the design system? Or sort functionality on a data table? Build it, and ship the product. But let the design system team know what this new or improved thing is out there, so it doesn’t exist in a silo.Change/deviation is NOT OK
If you need a button, then you use the design system button, both the design and the code. You can’t change its color, or shape, or decide you want to code it in a different way.
Making the “OK” aspects as positive, and robustly supported, as possible, encourages adherence to the restriction on deviation. Equally important is a clear, responsive, avenue for making change and improvement requests. The intent is not for the design system to be static and inflexible. If someone really wants to change the button, then they can propose that change, backed up by research and data.
Abloh highlighted the potential creative impact of small changes. A design system should encourage creative progression. The alternative is stagnation. But governance does two important things. It brings direction, a default behavior. That eliminates the fracturing where no default exists, or is ill-defined. And it provides a methodology to desired change. That means change, when it comes, is done with consideration and intent. It comes in a way that maintains the consistency and integrity of the design system as a whole.
Further reading:
The Percentage of Creativity, by Virgil Abloh, Domus magazine