What are design tokens?

Salesforce initially launched design tokens to streamline design
updates to a number of
platforms.

The Design Tokens Group Group describes design tokens as “a
methodology for expressing design choices in a platform-agnostic manner so
that they are often shared throughout completely different disciplines, instruments, and
applied sciences

Let’s break this down:

• Cross-Disciplinary Collaboration: Design tokens act as a standard language
  that aligns designers, builders, product managers, and different disciplines. By
  providing a single supply of reality for design choices, they be sure that
  everybody concerned within the product life cycle is on the identical web page, resulting in extra
  environment friendly workflows.
• Software integration: Design tokens may be built-in into numerous design
  and growth instruments, together with UI design software program, token editors, translation
  instruments (code turbines), and documentation programs. This allows design updates
  to be shortly mirrored within the code base and are synchronized throughout groups.
• Expertise adaptability: Design tokens may be translated into completely different
  applied sciences like CSS, SASS, and JavaScript for the net, and even used on native
  platforms like Android and iOS. This flexibility allows design consistency
  throughout a wide range of platforms and units.

Absolutely automated pipeline

Essentially the most easy approach to design the pipeline could be a
absolutely automated trunk-based workflow. On this setup, all adjustments
pushed to the principle department will likely be instantly deployed so long as they
move the automated high quality gates.

Such a pipeline may encompass the next jobs:

1. Examine: Validate the design token information utilizing a design token validator
   or a JSON validator.
2. Construct: Use a translation device like Model
   Dictionary to transform design token information into
   platform-specific codecs. This job may also construct the docs utilizing the
   translation device or by integrating a devoted documentation device.
3. Check: This job is very depending on the testing technique. Though
   some assessments may be accomplished utilizing the design token file straight (like checking the
   shade distinction), a standard strategy is to check the generated code utilizing a
   documentation device comparable to Storybook. Storybook has wonderful check
   help for visible regression
   assessments, accessibility assessments, interplay assessments, and different check sorts.
4. Publish: Publish up to date tokens to a package deal supervisor (for instance,
   npm). The discharge course of and versioning may be absolutely automated with a package deal
   publishing device that’s based mostly on Standard
   Commits like
   semantic-release.
   semantic-release additionally permits the deployment of packages to a number of platforms.
   The publish job may also deploy documentation for the design tokens.
5. Notify: Inform groups of the brand new token model by way of e mail or chat, so
   that they’ll replace their dependencies.

Determine 3: Absolutely automated deployment pipeline

Pipeline together with handbook approval

Typically absolutely automated high quality gates will not be ample. If a
handbook evaluation is required earlier than publishing, a standard strategy is to
deploy an up to date model of the documentation with the newest design
token to a preview atmosphere (a short lived atmosphere).

If a device like Storybook is used, this preview may include not
solely the design tokens but in addition present them built-in with the
elements used within the software.

An approval course of may be carried out by way of a pull-request workflow.
Or, it may be a handbook approval / deployment step within the pipeline.

Determine 4: Deployment pipeline with handbook approval

Choice tokens: defining what design choices are offered

Choice tokens (additionally referred to as primitive tokens, base tokens, core
tokens, basis tokens or reference tokens) outline what
kinds can be utilized within the software. They outline issues like shade
palettes, spacing/sizing scales or font households. Not all of them are
essentially used within the software, however they current affordable
choices.

Utilizing our instance, let’s assume we now have a shade palette with 9 shades for every shade,
starting from very gentle to extremely saturated. Beneath, we outline the blue tones and gray tones as option-tokens:

{
  "shade": {
    "$sort": "shade",
    "choices": {
      "blue-100": {"$worth": "#e0f2ff"},
      "blue-200": {"$worth": "#cae8ff"},
      "blue-300": {"$worth": "#b5deff"},
      "blue-400": {"$worth": "#96cefd"},
      "blue-500": {"$worth": "#78bbfa"},
      "blue-600": {"$worth": "#59a7f6"},
      "blue-700": {"$worth": "#3892f3"},
      "blue-800": {"$worth": "#147af3"},
      "blue-900": {"$worth": "#0265dc"},
      "grey-100": {"$worth": "#f8f8f8"},
      "grey-200": {"$worth": "#e6e6e6"},
      "grey-300": {"$worth": "#d5d5d5"},
      "grey-400": {"$worth": "#b1b1b1"},
      "grey-500": {"$worth": "#909090"},
      "grey-600": {"$worth": "#6d6d6d"},
      "grey-700": {"$worth": "#464646"},
      "grey-800": {"$worth": "#222222"},
      "grey-900": {"$worth": "#000000"},
      "white": {"$worth": "#ffffff"}
    }
  }
}

Though it’s extremely helpful to have affordable choices, possibility tokens fall brief
of being ample for guiding builders on how and the place to use them.

Determination tokens: defining how kinds are utilized

Determination tokens (additionally referred to as semantic tokens or system tokens)
specify how these fashion choices ought to be utilized contextually throughout
the UI.

Within the context of our shade instance, they may embrace choices like the next:

• grey-100 is used as a floor shade.
• grey-200 is used for the background of disabled components.
• grey-400 is used for the textual content of disabled components.
• grey-900 is used as a default shade for textual content.
• blue-900 is used as an accent shade.
• white is used for textual content on accent shade backgrounds.

The corresponding determination token file would appear like this:

{
  "shade": {
    "$sort": "shade",
    "choices": {
      "floor": {
        "$worth": "{shade.choices.grey-100}",
        "description": "Used as a floor shade."
      },
      "background-disabled": {
        "$worth": "{shade.choices.grey-200}",
        "description":"Used for the background of disabled components."
      },
      "text-disabled": {
        "$worth": "{shade.choices.grey-400}",
        "description": "Used for the textual content of disabled components."
      },
      "textual content": {
        "$worth": "{shade.choices.grey-900}",
        "description": "Used as default textual content shade."
      },
      "accent": {
        "$worth": "{shade.choices.blue-900}",
        "description": "Used as an accent shade."
      },
      "text-on-accent": {
        "$worth": "{shade.choices.white}",
        "description": "Used for textual content on accent shade backgrounds."
      }
    }
  }
}

As a developer, I might principally have an interest within the choices, not the
choices. For instance, shade tokens usually include a protracted record of choices (a
shade palette), whereas only a few of these choices are literally utilized in
the applying. The tokens which are really related when deciding which
kinds to use, could be often the choice tokens.

Determination tokens use
references to the
possibility tokens. I consider organizing tokens this fashion as a layered
structure. In different articles, I’ve typically seen the time period tier being
used, however I believe layer is the higher phrase, as there isn’t a bodily
separation implied. The diagram beneath visualizes the 2 layers we talked
about up to now:

Determine 5: 2-layer sample

Part tokens: defining the place kinds are utilized

Part tokens (or component-specific tokens) map the determination
tokens to particular components of the UI. They present the place kinds are
utilized.

The time period part within the context of design tokens doesn’t at all times
map to the technical time period part. For instance, a button is likely to be
carried out as a UI part in some purposes, whereas different
purposes simply use the button HTML factor as an alternative. Part
tokens may very well be utilized in each instances.

Part tokens may be organised in a group referencing a number of determination tokens. In our instance, this references
may embrace text- and background-colors for various variants of the button (main, secondary) in addition to disabled buttons.
They may additionally embrace references to tokens of different sorts (spacing/sizing, borders and so on.) which I will omit within the
following instance:

{
  "button": {
    "main": {
      "background": {
        "$worth": "{shade.choices.accent}"
      },
      "textual content": {
        "$worth": "{shade.choices.text-on-accent}"
      }
    },
    "secondary": {
      "background": {
        "$worth": "{shade.choices.floor}"
      },
      "textual content": {
        "$worth": "{shade.choices.textual content}"
      }
    },
    "background-disabled": {
      "$worth": "{shade.choices.background-disabled}"
    },
    "text-disabled": {
      "$worth": "{shade.choices.text-disabled}"
    }
  }
}

To a point, part tokens are merely the results of making use of
choices to particular elements. Nevertheless, as this
instance reveals, this course of isn’t at all times easy—particularly for
builders with out design expertise. Whereas determination tokens can provide a
common sense of which kinds to make use of in a given context, part tokens
present extra readability.

Determine 6: 3-layer sample

Be aware: there could also be “snowflake” conditions the place layers are skipped.
For instance, it may not be potential to outline a common determination for
each single part token, or these choices may not have been made
but (for instance in the beginning of a venture).

File-based scope

Utilizing Model Dictionary, we will use a
filter to
expose solely public tokens. Essentially the most easy strategy could be to
filter on the file ending. If we use completely different file endings for part,
determination and possibility tokens, we will use a filter on the file path, for
instance, to make the choice tokens layer personal.

Model Dictionary config

  const styleDictionary = new StyleDictionary({
    "supply": ["color.options.json", "color.decisions.json"],
    "platforms": {
      "css": {
        "transformGroup": "css",
        "information": [
          {
            "destination": "variables.css",
            "filter": token => !token.filePath.endsWith('options.json'),
            "format": "css/variables"
          }
        ]
      }
    }
  });

The ensuing CSS variables would include
solely these determination tokens, and never the choice tokens.

Generated CSS variables

  :root {
    --color-decisions-surface: #f8f8f8;
    --color-decisions-background-disabled: #e6e6e6;
    --color-decisions-text-disabled: #b1b1b1;
    --color-decisions-text: #000000;
    --color-decisions-accent: #0265dc;
    --color-decisions-text-on-accent: #ffffff;
  }

A extra versatile strategy

If extra flexibility is required, it is likely to be preferable so as to add a scope
flag to every token and to filter based mostly on this flag:

Model Dictionary config

  const styleDictionary = new StyleDictionary({
    "supply": ["color.options.json", "color.decisions.json"],
    "platforms": {
      "css": {
        "transformGroup": "css",
        "information": [
          {
            "destination": "variables.css",
            "filter": {
              "public": true
            },
            "format": "css/variables"
          }
        ]
      }
    }
  });

If we then add the flag to the choice tokens, the ensuing CSS would
be the identical as above:

Tokens with scope flag

  {
    "shade": {
      "$sort": "shade",
      "choices": {
        "floor": {
          "$worth": "{shade.choices.grey-100}",
          "description": "Used as a floor shade.",
          "public": true
        },
        "background-disabled": {
          "$worth": "{shade.choices.grey-200}",
          "description":"Used for the background of disabled components.",
          "public": true
        },
        "text-disabled": {
          "$worth": "{shade.choices.grey-400}",
          "description": "Used for the textual content of disabled components.",
          "public": true
        },
        "textual content": {
          "$worth": "{shade.choices.grey-900}",
          "description": "Used as default textual content shade.",
          "public": true
        },
        "accent": {
          "$worth": "{shade.choices.blue-900}",
          "description": "Used as an accent shade.",
          "public": true
        },
        "text-on-accent": {
          "$worth": "{shade.choices.white}",
          "description": "Used for textual content on accent shade backgrounds.",
          "public": true
        }
      }
    }
  }

Generated CSS variables

  :root {
    --color-decisions-surface: #f8f8f8;
    --color-decisions-background-disabled: #e6e6e6;
    --color-decisions-text-disabled: #b1b1b1;
    --color-decisions-text: #000000;
    --color-decisions-accent: #0265dc;
    --color-decisions-text-on-accent: #ffffff;
  }

Such flags can now even be set via the Figma
UI
(if utilizing Figma variables as a supply of reality for design tokens). It’s
out there as
hiddenFromPublishing
flag by way of the Plugins API.

When to make use of design tokens

1. Multi-Platform or Multi-Software Environments: When working throughout
   a number of platforms (net, iOS, Android…) or sustaining a number of purposes or
   frontends, design tokens guarantee a constant design language throughout all of
   them.
2. Frequent Design Adjustments: For environments with common design
   updates, design tokens present a structured approach to handle and propagate adjustments
   effectively.
3. Giant Groups: For groups with many designers and builders, design
   tokens facilitate collaboration.
4. Automated Workflows: In the event you’re conversant in CI/CD pipelines, the
   effort so as to add a design token pipeline is comparatively low. There are additionally
   business choices.

When design tokens may not be needed

1. Small initiatives: For smaller initiatives with restricted scope and minimal
   design complexity, the overhead of managing design tokens may not be definitely worth the
   effort.
2. No problem with design adjustments: If the velocity of design adjustments,
   consistency and collaboration between design and engineering will not be a difficulty,
   then you may also not want design tokens.