Generalizing the Design Tokens Solution

Design tokens solve a particular problem.

Design tokens are tech-agnostic encapsulations of design specifications that can be formatted into tech-specific assets (e.g. CSS variables).

It’s a particular solution, but I reckon that it may be generalized to other problems in software engineering.

Consider linting rules. They are effectively our “code specs,” encapsulations of code style, format, and principles.

We are familiar with tech-specific linting rules that encapsulate our code specs (e.g. EsLint). However, in theory, there is likely some overlap of code specs across technologies.

How come there is no equivalent to Style Dictionary where a build tool can take the tech-agnostic code specs and format them into tech-specific linting rules (i.e. a chunk of a .eslintrc file)?

Perhaps, this is a novel idea — or, perhaps I am naive. My sneaking suspicion is that it is neither.

Design tokens have created a buzz in the web development community because they inherently have a sponsor.

The artistic designers, with their neat graphics and documentation, sponsor the work of developers to create technical solutions that indirectly contribute to the bottom line.

When it comes to the hypothetical “code tokens,” there is no sponsorship outside of the developers — and, secondarily, no neat graphics, documentation, and online community/buzz.

Code tokens would be indirect developer work that may not be seen as contributing to the bottom line, and therefore, no contributors can release their creativity to build a powerful build tool.

Even in organizations that do empower developers to work on indirect-bottom-line-but-powerful work, the project would need an equally powerful sponsor since the convenience is limited to the developers and not the designers and product managers.

So, can we apply the particular solution of design tokens to other problems (like sharing code tokens)?

We definitely can, but it requires sponsorship, and from that sponsorship, a robust online community and buzz.

While my main motive in this article is to stimulate others to build upon my ideas (e.g. building a code tokens pipeline), it brings up a tangentially related point.

Maybe the lack of powerful developer tools that solve problems similar to design tokens is not a lack of knowledge — seeing the logical parallel is pretty easy to grasp.

Neither is it a lack of empowerment — although, many organizations need to empower developers to be creative in indirect-to-bottom-line work.

Perhaps, it is a lack of sponsorship to create buzz around tools that solely improve the efficiency of developers and not outside cogs in the wheel.

To put it positively, not only should we consider design-tokens-like solutions, but we should also consider intentionally aggregating sponsors that can breathe life into these important efforts.