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.

--

--

--

https://leanpub.com/designsystemsfordevelopers

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Designing For the Rest Of Us

Graphic Designing Checklist: Easy ways to conquer the virtual world

The Strength of Shapes — Part III

Asphalt With White Stripe PBR TEXTURE

Create a memorable event by including creative beverage ideas.

A 5-step guide to improve the UX of MDM systems

M59366 Louis Vuitton Nigo’s Colorful “LV Made” Tiger Tote Journey

Dog Daycare Web Redesign: A Case Study

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Michael Mangialardi

Michael Mangialardi

https://leanpub.com/designsystemsfordevelopers

More from Medium

Declarative design systems

My opinion on dark mode in 2022

The New Land-book Is Coming. Again!

Introducing the new Land-book PRO

Kaizen : Scaling with Beaconstac’s Design System