McKirgan.com

Note: the image for this article was generated by DALL-E II "Design tokens are design decisions, represented as data, that ensure systematically unified and cohesive product experiences." Source: Adobe: Design Tokens Data Duplication Data Duplication is a software design antipattern where data is being unnecessarily duplicated across one or more storages. In my experience, developers are good at spotting this problem. It may come in the form of 2 databases not talking to each other, or 2 systems needing to work with unnormalised data in slightly different ways. Data Duplication in systems is often there either for convienence or trade-off - because it's easier to implement, or the cost of de-duplicating is seen as worthwhile enough. The latter can often be the case when working with uncentralised marketing analytical information, or perhaps because a 3rd party system can exchange data at a pace or latency required by other systems. Nonetheless, it's widely agreed that duplicating data in any form should be avoided. There's rarely a scenario that favours duplication, rather than tollerating it. What do design tokens look like? @TODO Design Data and the problem of duplication When front-end developers work from design documents, such as Figma, the whole process historically has been entirely data duplication. The designer places data about their designs into a storage engine, be that a Photoshop file, Sketch document, or a Figma design. Data such as width, color, font family, border radius, font weight, line height - the list goes on. A good designer knows they need to normalise their own design data. This can come in the form of brand guidelines, where designers either are using Figma components or else are trying their best (with the unfortunate assistance of human error) to not change various design data when adding, say, a header to a new screen of an app. The developer comes along, and through a very tedious manual process, is copying this data into hopefully, some kind of normalised design/theming system which will help aid the process and reduce data duplication. The problem with all this, is designers and developers alike are not recognising this as data at all. They've made the age-old mistake of creating two sourcing of truth for design data - the designer's document, and the developer's theming tool in code. Besides the human error which can create mistakes, there are more issues here. What happens in 2 months time when the designer realises they've used the wrong font, the border radius everywhere doesn't match the website's, or the primary color is off slightly? The developer now introduces more chance of human error as they attempt to replace instances of data throughout the codebase or theming system. They perform the role of a squishy stressed-out, caffienated, deadline-driven robot with varied success. The problem is this;

if we want to build and maintain design consistancy, we need to start with a single source of design data in our design pipeline

How do we practically use Design Tokens? It starts in design There's a bunch of approaches to this question, and we can't go over all possibilities, that'll require real discussions with your own teams about their ways of working, and development processes. What is key, is identifying the storage of current design tokens (if any), then finding a plan to unify them to consume a single-source-of-truth (SSoT). For a designer these days, that may involve creating components in Figma inside a seperate design token document, where all data about those components consumes a standardised naming convension. For example, you may create a series of headings: heading1, heading 2, heading 3, etc., which all consume a font family which is commonly named, such as roboto.500, where roboto is the font family name, and 500 is the weight. That same series of heading components will likely consume differing font sizes, perhaps: "26, 22, 18" for our 3 headings. If we name these consistantly, we are creating a normalised set of data which describes each heading. There are Figma extensions which help manage this for you, providing you with a template to begin your work from, then referencing that template as a published library in your figma design files. If you're using tools such Adobe's vector suites, there are simular tools baked-in. From design to development Now you've got your design creating a normalised data source of design tokens, we theoretically can export these tokens into all of our front-end applications to consume the data. The challenge is getting the data out in the first place. There is a remarkable lack of tooling in the market to achieve this well. So as far as I have discovered, for Figma at least, you have 2 choices: get your development team to build their own pipeline using the likes of the Figma API to export and store tokens, or else use a 3rd party service to achieve it, the best in market at the time of writing is SpecifyApp. SpecifyApp is SAAS; providing a intuitive UI interface to export design tokens from Figma documents and channeling them to a secured API. They offer complex configuration and transformation of design data, and offer commandline SDK which can easily integrate into package.json commands. Adding an integration to pull the latest design tokens becomes as easy as, yarn run designTokens:sync once setup correctly. In my latest project, I had these pull into a json file, inside a project generated directory. From there, I the same yarn script also transformed the json format slightly to conform to our specify json token library's format. Syncing it all Now, when a designer informs a developer on our team there are changes to a font, instead of us having to spend hours going through our entire front-end codebase, and risking human error, we just sync tokens, and run a release. All of our designs are now corrected. Finally, we are able to hand over the reigns, albeit with limitations, from development to design, and give designer control. Limitations @TODO