Win Friends, not Battles.
Design Codification, if done right, enables teams to collaborate much more naturally and empowers designers by providing them with powerful levers. This is why we should make our design system's code repository our main canonical repository. Whatever is defined in the code repository should ideally represent the ultimate truth from which we derive everything else. Any further documentation should complement it. However, we don't necessarily need a comprehensive component library right away. The concept of
Design Tokens(and the tactic of the same name) is a great place to start the process of
Design Tokensallow us to codify our UI components step by step in a bottom-up manner.
Radical Modularityproposes a flexible UI architecture that utilizes 3rd party front-end frameworks to help us with some of the heavy lifting in building digital products. Both concepts are compatible with all modern UI development paradigms, including utility-first and CSS-in-JS approaches.
UI Kitlives in a modern UI design tool such as Figma, Adobe XD, or Sketch. While some of these tools provide ways to generate code automatically, the corresponding workflows can make us too dependent on a specific tool or framework. Also, the code quality may not be up to scratch, as there are semantic gaps that still prove hard to bridge from this side of the handoff process. Instead, Lean Design System promotes the adoption of
Design Tokensas a much more effective and fluent approach to the integration of design and development efforts. For that reason (and as we can see in fig. 1), the
UI Kitshould always be based on the latest definitions in our code repository. In other words, we quite literally trace components exactly as they are rendered on devices and make them available as design components within our
UI Kit. What may seem a bit cumbersome at first will ensure that the
UI Kitnever takes the lead over the code repository. A component that can't be easily built using our technology should not be part of our
UI Kit. This way, prototypes we design will always be close to the real thing and all testing we perform will be valid. We should always only have one central and shared
UI Kitfile (or file structure in the case of a very large or complex component library).
UI Kit(as meta text elements).
Minimum Viable Design Systemsuggests to maintain a simple knowledge hub in which we reference all elements and processes our design system encompasses. Beyond that, a set of design principles can help explain the reasoning behind our design and development decisions. Just like with our
UI Kit, any textual documentation must not contradict the definitions in our code repository. See also:
A Living Handbook.
UI Kit. Ideally, UX Vignettes should be clickable and run on all targeted platforms. When determining our design tooling, prototyping capabilities should be a main criteria, as the process of building, testing and updating them should be quick and easy. If we want to make improvements or add new elements to our
UI Kit's component library (because, for example, a project presents us with a new and unique challenge), we document them in separate Tweaks files. These Tweaks files are shared design files in our design system stream.
UI Kitin separate Tweaks files, which are shared design files of the same type as the
UI Kititself. Tweaks can be the result of project work or regular optimization efforts. Whatever their origin, if we agree on their validity, we feed them into the code repository through the process of codification. Once codified, we can then make them available in our
UI Kitby tracing them.
Every project we work on and every prototype we design can produce tweaks that flow downstream until they reach our code repository—from where they benefit everything we build henceforth.
Design Tokensrepository. Once our infrastructure reaches a sufficient level of maturity, all improvements we make can even be propagated directly into live products.