Idea: Event-based design tokens versus centralized design tokens

🧵

Here is a simplistic example of how design tokens are derived from Figma but serve as the central source of truth for design specifications in code.

Consuming applications treat design tokens as read-only--neither extending nor normalizing them. 

Logically, this makes sense. If we have a single source of truth for design tokens, every consuming application will have the same design specifications (which is the whole point).

However, it means that...

1) Each consumer has to source from a data set (the design tokens) that lives elsewhere (more risk of obscurity).

2) Each consumer is dependent on Figma to change in order to gain access to new tokens.

Well, obscurity can be fixed with good documentation.

And, you could build some pipeline where changes to the design tokens are reflected in Figma. Or, the design tokens can extend and alias (but not mutate) the Figma specifications in a way that makes everyone happy.

However, what if Product A has its own product-specific specifications and wants to add them to the design tokens?

Developers on this team could contribute directly to the design tokens--but that is outside work and may not be fitting for the centralized tokens.

These considerations are analogical to the debate about microservices.

You can design a microservice that is the source of truth for some domain/concept (e.g. products, licenses).

Each product consumes the microservice when it needs to interact with the data of a given domain.

Design tokens are effectively a microservice serving as a source of truth of a domain/concept, the design specifications.

In the microservices world, some suggest moving away from a single source of truth.

Instead of centralized microservices that each product queries from, each product has its own data source from which it queries.

Doesn't this lead to duplication of data if a product shares domain data with another product?

Not always. Each product that manages a domain may emit an event when changes to a domain are made.

e.g. if a product manages licenses, and it can emit an event when licenses change.

Other products dependent on that domain can subscribe to the event, ingest the domain data, and store the domain data into their own data source as it sees fit.

Now, products can not duplicate data while not having to rely on centralized dependencies.

Ok, so if design tokens are a type of microservice, in that they manage the data of a domain--the design specifications, then we can apply the event-based model for sharing domain data, for sharing design specifications.

What if...when Figma changes (the source of the design specifications domain), it emits an event with the new design specifications.

Then, each product ingests the specs and translates them into its own design tokens source. 

*same image*

If a product needs to reference design tokens, it references its own source.

It cannot mutate the specs, but it can alias and extend them as needed.

Since the tokens are owned by each product, they are less obscure and not dependent on a central service/team. 

What are the implications of this?

Not only would this event-based model of design tokens reduce technical complexity--it would also reduce organizational complexity (since the relationship is symbiotic).

You eliminate the need to gatekeep design tokens through a separate team.

How did I come up with this?

I read up on the microservices problem and made the application to design tokens, seeing an analogy:

https://betterprogramming.pub/the-truth-about-your-source-of-truth-a1eb833c2d70

If you enjoy philosophical takes on software architecture and organization, you may like my latest mini-ebook (it's free+): https://leanpub.com/rethinkingagile

Event-Based Design Tokens Versus Centralized Design Tokens (And What That Means for Organizations)

Thread: You're no longer a junior developer, so what type of role do you take on next?

Generally, there are 3 types of work for a web developer:

1) Stream work - Creating new features on a product or API service

2) Platform work - Keeping up a platform via bug fixes, CI/CD, dependency upgrades, etc.

3) Enabling work - Specialized work to bring code to an ideal

Stream work includes close collaboration with a product team and affords the most direct level of influence over an end product. It is focused work with opportunities for creativity when implementing features, creating code patterns, suggesting business solutions, etc.

The cons of this work are that you don't always get the time to develop your craft. Stream work may be combined with platform and enabling work which can be either a learning experience or a theft of focus.

The work is only as exciting as the features--which you don't control.

If you love debugging then you'll love platform work. It is not as creative as the other types of work, but it is foundational to the success of any application. It requires the least collaboration with non-technical people and has a predictable cadence to it. Some dig this.

Enabling work is the most specialized. You can work on creating tools and assets that help a variety of engineering teams across a company. You can focus on developing your craft and stimulating creativity without the usual distractions. An example is working on a design system.

Enabling work is influential to products but in a more indirect way. If you prefer to be more of a jack of all trades and/or collaborate about feature development, stream work can be a better fit.

In order to know what you want to do, you first need to evaluate what you are currently doing.

Are you doing stream, platform, or enabling work (or a combination of each)?

Now, evaluate your enjoyment of this type of work.

Next, is there a type of work that seems most appealing to you? What would make you tick? What aligns with your skills and interest?

If you aren't sure or like doing a little bit of everything, stream work at a non-enterprise company is usually the way to go.

If you want to focus on one type of work, you need to be careful to ensure you only sign up at a place with mature engineering organizations and processes.

If you want to do 2/3 types of work, you will either need to take initiative to say no to a certain type of work (i.e. platform work), or you will need to take initiative to be more involved in another type of work (i.e. informally work closely with the design system team).

What's your mental model for determining what type of work you want to do?

3 Types of Work for Web Developers to Specialize In

Here's how I'm using Figma Tokens in a professional use case:

✅ Allow designers to update design tokens in Figma rather than GitHub

✅ Open a PR when changes in Figma are finalized

✅ Have developers subscribed to repo to get notified of a new release

✅ Allow developers to provide input, finalizing the tokens "contract"

✅ Use the tokens synced from Figma as the "raw"/base tokens in the Style Dictionary pipeline

✅ Use GitHub actions to build the new "formatted" tokens when the PR initiated from Figma is merged

✅ Include "normalization" in the Style Dictionary build process to shape the tokens to the preference of the developers

Thanks @six7 for all the hard work 😊

To clarify, the developers provide input, helping to mold the tokens "contract," by conversing on the PR, making suggestions as needed.

Figma Tokens Pipeline: A Professional Use Case

Here's my system for being productive:

- Capture seasonal projects/goals
- Create a kanban board of tasks for the week
- Pull tasks to a todo list for the day
- Distinguish stretch goals from musts
- Carry over incomplete tasks to the next day
- Track tasks that crept up

Interestingly, I recently found there's a product similar to this system: https://ugmonk.com/ *

* Not an affiliate link

No fancy app or journal. Just a moleskin notebook and bring it with me (mostly) everywhere.

An Easy System for Being Productive

I’ve previously written about how you can start a design tokens pipeline by building our “raw” tokens in Style Dictionary and formatting them for various platforms. Then, you can build a Tailwind config (for example) off of that. 

But, can you change that order?

The theory behind having raw tokens that can be formatted (via Style Dictionary) is that it you can expose primitive tokens that can be consumed by any platform before you develop more sophisticated assets.

In a word, you build raw, platform-agnostic tokens that are programmatically formatted for N amount of platforms instead of starting with formatted tokens.

The impetus is that you ensure that all consumers (even future ones) will have a way to apply official design system specs to their application.

But, couldn’t we still achieve that goal if we started with formatted tokens and just made sure to un-format them in the pipeline?

It feels more organized in a mental model to start with raw tokens and then to format them.

The downside is that starting with raw tokens also means starting off with raw tools/assets. It can be exhausting to manually enter them without the ease of let’s say utility classes.

What if we built tools to compose raw tokens as easily as we can compose formatted tokens (like composing Tailwind classes, for example)?

Idea: Start with the primitive value tokens of your design system (i.e colors, typography, spacing) and create utility classes for them via a config consumed by Tailwind (or similar). Use these classes to compose the tokens for component-level tokens.

Finally, Style Dictionary (or similar) would take the Tailwind config and component-level tokens, formatting the config for different platforms, while also un-formatting the aggregated, component-level utility classes for various platforms.

In summary, the main bottleneck for creating a Style Dictionary pipeline is creating the component-level, raw tokens. Some have turned to Figma plugins, great. But, what other efficient options are there?

Using Tools (Like Tailwind) to Generate Tokens More Quickly

Here's an idea that I'm currently developing...

A @storybookjs addon that extracts the Style Dictionary-friendly design tokens out from the current story.

Here's why this is helpful: 

1) For documentation (without having to jump back and forth between Style Dictionary).

2) For allowing teams to build UI components as usual, copy and paste the underlying, agnostic tokens into a tool like Style Dictionary, and then format them for sharing with other teams.

This flips the traditional approach to a design tokens pipeline. Instead of generating your tokens first, and then consuming them in your UI library, you can create the UI library first and then extract the tokens.

In a word, you can reverse engineer a design tokens pipeline.

This may not be an ideal use case or best practice, but it could be helpful in SOME cases (i.e. a team that only has a UI component library, no formal design system team, and wants to quickly get a Style Dictionary pipeline going.)

Here's the WIP: https://github.com/michaelmang/addon-kit

Created the addon, here's the diff that summarizes how I built this: https://github.com/michaelmang/storybook-tokens/commit/e86294e73870b015455cc5bf15cc18296c306abc

A Backwards Design Tokens Pipeline: Generating Tokens From React (An Experiment)

I often hear the following objections to building a design-tokens based design system:

1. We’re only concerned with a React UI library for now.
2. Who’s going to create the design tokens? Seems like more work.

In a word, how can we use design tokens when we don’t have the time?

I commonly emphasize the need for developers to take ownership of advocating for the usefulness of a design system and to start getting it off the ground with a POC: https://specifyapp.com/blog/becoming-a-design-tokens-ambassador

But, let me give an alternative answer.

The main reason for creating design tokens BEFORE you create platform/technology specific assets (like a React UI library) are:

1. You have a single source of truth (DRY).
2. You can expose the underlying design specs for other platforms and technologies.

Which means...

To get these benefits you need the design tokens so others can consume the design specs for their preferred platform/technology without needing to buy into React (hence it seems logical to build design tokens BEFORE the React library).

But, what if we reversed the approach?

Instead of building the design tokens first, what if we could derive component-specific design tokens from already-existing React components?

Theoretically, this would resolve both objections I mentioned in the outset:

1. You could extend your React UI library by exposing design tokens from its component (not refactoring it).
2. You could save time by letting your existing React components make the design tokens.

Technically, how could we derive design tokens from a React component?

It’s 3AM EST, and I just had this idea pop in my head a half hour ago, but here’s my idea:

1. Document your React components using PropTypes or TypeScript, specifying `variant` and `size` props with valid options.
2. Use react-docgen to get the prop info.

3. Get the computed “size” styles (by seeing what style properties change when you change the size prop, then getting the style key and value (the token) for each size prop).

4. Get the computed “variant” styles (by subtracting the “size” styles from the remaining computed styles for each variant prop).

5. You can then shape the results into a Style Dictionary-like tree:

```
component
  {component name}
    primary
      {...primary computed styles}
    {...repeat for other variants}
    sizes
      small
        {...small computed styles}
      {...real for other sizes}
```

Then, you build formatted design tokens for other platforms as needed.

If someone could extract this React-to-tokens middleware, this might be a net positive (although not ideal) solution for some teams that are in a pinch.

Let’s call the middleware “react-tokengen”?

Considering building said middleware, but what do you think?

My main objection to this is approach is that automation for generating design tokens has to be based on template.

This means that designers have to refactor/organize their files into said template. Or, devs have to refactor their code into a template (variant and size props).

Said refactoring could take more time then building design tokens from scratch. If you can write CSS, you can manually create design tokens. Sure, it comes with some friction at first for the developer experience.

It feels like a bandaid solution to ideal approach of building a design tokens build process that is then consumed by a React UI library.

But, would a not-as-ideal option be worth it?

Here's a rough start to this idea: https://gist.github.com/michaelmang/a9484fd5f107161cda54b7903b2ef7eb

Creating Tokens After a React UI Library

Problem:
There are no small amount of frontend engineers who would love to have a design system but designers are busy making prototypes for product workflows and haven’t organized a design system.

In such a scenario, what can you do?

Reverse engineer the design system.

Go over the prototypes that have been handed off to you from the designers.

Try to detect the patterns for colors, typography, spacing, etc.

Do your best to distinguish certain components that are generic enough for a design system.

Chances are that you’ll be able to have enough for a primitive design system. Start building a design tokens-based design system and generate UI assets.

Then, you have leverage to present your work to other devs and designers to get everyone onboard to invest in the project.

Reverse Engineer a Design System

What is the intersection between a design tokens pipeline (a la Style Dictionary) and @tailwindcss?

By transforming formated JS tokens into a Tailwind config, you can use Tailwind to compose your tokens easily via utility classes.

Even better...

Tailwind can fill in the gaps for "simple" tokens (i.e. colors, typography spacing) if your design system doesn't have one.

Should your design system become more extensive to include official spacing specs, then you override Tailwind with minimal changes to the dev experience.

In a word, creating a Tailwind config from formatted design tokens gives you an asset that allows you to compose formatted design tokens in an ideal, expedited way.

The Intersection Between a Design Tokens Pipeline and Tailwind

I created a @GatsbyJS source plugin that sources your latest threads from Twitter: https://github.com/michaelmang/gatsby-source-twitter-threads

Here's an example of using this in order to generate a blog:
https://github.com/michaelmang/gatsby-source-twitter-threads

There are some limitations as the Twitter API only returns the previous 7 days' worth of threads. However, I think there could be a workaround to use threads for a full-fledged blog source: https://github.com/michaelmang/gatsby-source-twitter-threads#limitations

Example 🔥 

This was created from: https://twitter.com/michaelmangial1/status/1448289062041890820 

Definitely some work that could be done to improve formatting. 

If you're interested, please contribute on GitHub.