Dear (none)Designer,
Welcome back to the nineteenth Design at Scale™ Newsletter – focusing on innovation and how design drives change in a large organisation or an agency.
When mentioning the design system, we often see that development has to suffer the consequences of translating the visual Design to Code.
The business has an idea that is often translated into a brief, which is then translated into the project identification document. This document defines the user stories, which are then translated into a screen reflecting a specific behaviour. This behaviour is then documented in the form of elements and patterns, and these patterns are built from scratch in the code, which (sometimes) is miles away from the original business idea.
Why? Over five decades of building software, we continue to build houses, brick by brick. No one has ever considered a closer relationship between design and development, so that the formal design decision does not have to be translated twice and built from scratch again on the other side of the fence.
I often question my engineering teams about why we don’t build everything in basic HTML and CSS first, before we approach the significant and robust CMS systems that impose constraints on the original proposed solution.
UI kits have introduced the first version of visual patterns. Now, with tokenise design systems, we do have a bridge defined by a JSON file that represents the ultimate handshake between design and development. We therefore dictate what and how it will be built, as well as how it should behave in a specific viewport within a specific environment and under a specific situation.
Giving a complete description of business objectives measured by the KPIs to our engineering colleagues to focus on clarity and optimisation of the code, instead of how do I build this module type of thing?
We are not suggesting copying the code from Figma, yet. There will be a time when Figma releases a more robust dev tool to allow an even greater handshake between the two disciplines.
More importantly, once we deploy the first JSON file, we can begin consuming it in design. This way, we will formally create a source of truth that is defined by the code. Whether this needs to be extended by another brand, with additional parameters, or patterns, we can constantly reflect on this very codebase as a reference point from which we can evolve.
Inevitable benefits of course versioning include ease of deployment, tracking, analysis, and, most importantly, performance improvement that is inherited with zero human translation or re-coding.
For more information, please visit Designa at Scale™ – GRID Magazine, where you can find additional relevant articles that explore hyper-performing teams, self-organising teams of one, teams of 10, and teams of 100 that deliver the value proposition within a product-led environment.
