Design Codification
Design Codification is the belief that all aspects shaping digital products should be defined as code, versioned, and collectively owned.
Last updated
Was this helpful?
Design Codification is the belief that all aspects shaping digital products should be defined as code, versioned, and collectively owned.
Last updated
Was this helpful?
In software design, there's a saying that "if it isn’t documented, it doesn’t exist." Design Codification is driven by the idea that "if it isn't codified, it won't persist." It's a guiding principle based on the belief that digital product development should be underpinned by semantic software code which can be written, reviewed, adapted, and owned by developers and (visual and UX) designers alike.
The systematic codification of design represents a lean approach to avoiding unwanted deviations from guidelines, as it minimizes (or even eliminates) the need for strict governance processes.
An effective design system will make our design and development successes repeatable and transferable. The systematic codification of design represents a lean approach to avoiding unwanted deviations from guidelines, as it minimizes (or even eliminates) the need for strict governance processes. Through collective code ownership (as outlined in ) and continuous optimization (as outlined in and ), a codified component repository matures with each project and interaction.
Digital products are composed of software code, and by embracing code as a building material, we unlock several powerful concepts and mechanisms related to the computational processing of digital media:
Software code can be stored and versioned in repositories. We can perform comparisons and mergers of different iterations. We can create forks and branches to experiment with and expand our libraries.
Repositories and versioning allow for collective code ownership, as we can easily trace, evaluate and revert changes.
Working on shared repositories also allows for sandbox environments and automated CI/CD pipelines to be established, which enable developers and designers to validate changes right away without having to wait for deployments.
The same concept makes it possible to propagate changes into already deployed products.
Codification allows for code-based manipulations of design artifacts at runtime, like coloring or animating icons using SVG and JavaScript, eliminating error-prone handoffs and tedious export processes.
Unlike written guidelines, software code is unambiguous, helping us to prevent unwanted variance.
Definitions stored as code provide us with powerful levers to make significant changes with little effort through inheritance and batch processing.
A code-based style repository can even allow us to generate automated documentation. It's almost trivial to build a simple web page previewing our component library, which directly imports definitions from our repository.
Design Codification, if done right, enables seamless communication and collaboration between design and development. It establishes a shared language that can be adopted by everyone working on digital products. Developers can learn about design-related nuances and dependencies through the codified structures, while designers gain a better understanding of the technical realities underpinning the technology they're working with—which will also help them take constraints into account much earlier in the process.
There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Carlton
To come up with a lasting naming system, we're encouraged to examine and discuss the structure and relationships of our UI components, as well as the global rules and guidelines underpinning our brand. It may take a fair bit of negotiation and mediation (between different domains and viewpoints) until we can agree on a system that will work just as well for our designers as for our developers, but efforts like this will considerably improve our product development practices long-term.
Ultimately, the process of Design Codification can result in a fully codified design system with automated pipelines, automated documentation, and highly interweaved collaboration between design and development. But there are many incremental steps we can take towards this goal and even explore hybrid approaches in which we only codify certain aspects of our design work. Listed below are three low-barrier examples for Design Codification:
Information architecture can be documented in the form of a data model straight away. With the support of engineering, an information architect can maintain information so that it can be used directly for other purposes, like structuring databases or generating sitemaps.
Instead of requiring designers to code, the goal should be to create an environment that lets designers be designers, but enables cross-functional collaboration—and makes it easy to share ownership of UI components, even across domains. Design Codification can help bridge semantic gaps between design and development and serve as a common language in such an environment.
Design Tokens are a good way to get started with Design Codification and allow for a gradual approach to codifying style definitions and adopting collective ownership.
D. Kurfess
Naming components and variables correctly can be a daunting task. As a cross-functional exercise however, coming up with names as a team can drive collaboration and help build a shared understanding of the products we're developing. , short for Block, Element, Modifier, is one of many proven methodologies we can use as a basis for naming our UI components. For naming our , we can check the many open source design systems available online for reference.
Modern design tools like Figma make it easy to apply the same naming conventions we defined in our code repositories to our . By keeping naming consistent between our code and design sources we make sure everyone always speaks the same language.
are a great way to get started with Design Codification. are codified design attributes that can be defined, understood and applied by developers and designers alike.
Additional design system documentation can be written in markdown language and stored in a code repository directly alongside other codified design components, see .
Icons and vector illustrations can be stored as SVGs, enabling script-based manipulations like color changes, animations and lossless scaling. In the code example below, we just need to add a dark-mode class to our HTML at runtime to make all circle elements in our UI appear in the color GhostWhite. Of course, the color value and its semantic assignment can be pulled from a repository instead of a static CSS file.
So, does this mean designers of digital products will have to learn to code in order to successfully adopt Design Codification as a team? Well, only to a point where they become able to co-own codified design system artifacts, such as . Design Codification doesn't change the way we design. It does, however, change the way we maintain the results of our design work and what we consider canonical within our design system (see: ).
To catalyze the process of Design Codification, it may prove helpful to establish the role of a dedicated within the team—which might be filled by a former code-savvy designer, a former design-savvy developer, or a new hire—working specifically on the interfaces between design and development. According to Brad Frost's , a front-of-the-front-end developer is "a web developer who specializes in writing HTML, CSS, and presentational JavaScript code." A good understanding of (visual and UX) design and state-of-the-art UI implementation paradigms allows a dedicated front-of-the-front-end developer to fully grasp the respective goals and challenges.
