Was sind Design Tokens?

Ich höre in letzter Zeit viel von Design Tokens und obwohl ich noch nie an einem Projekt arbeiten musste, das sie benötigte, finde ich sie super interessant und es lohnt sich, ein paar Notizen dazu zu machen. So wie ich es verstehe, ist die allgemeine Idee folgende: Design Tokens sind eine agnostische Methode zur Speicherung von Variablen wie Typografie, Farbe und Abständen, damit Ihr Designsystem über Plattformen wie iOS, Android und normale Websites hinweg geteilt werden kann.

Design Tokens gewinnen in der Community der Designsysteme an Fahrt, sind aber kein völlig neues Konzept. Es gibt einen tollen Vortrag mit Jina Anne und Jon Levine aus dem Jahr 2016, in dem sie darüber sprechen, wie Design Tokens im Lightning Design System von Salesforce verwendet werden. Sie beschreiben die Komplexität der Welt, in der wir leben, wo eine einzelne Organisation, die mehrere Web-Apps und native Anwendungen entwickelt, gleich aussehen und sich gleich anfühlen muss, ohne das Entwicklungsteam zu verlangsamen. Jina hat auch einen ausführlichen Videokurs über Design Tokens erstellt, in dessen Vorschau sie schreibt:

Mit Design Tokens können Sie Low-Level-Werte erfassen und diese dann verwenden, um die Stile für Ihr Produkt oder Ihre App zu erstellen. Sie können ein skalierbares und konsistentes visuelles System für die UI-Entwicklung aufrechterhalten.

Nehmen wir nur ein Beispiel: Sie haben wahrscheinlich eine typografische Skala, die auf allen Plattformen identisch sein soll. Anstatt die Werte für diese Skala in einer CSS-Datei zu speichern und sie in jeder App oder Website zu replizieren, können sie in einer JSON-Datei gespeichert werden, die dann in den Code umgewandelt wird, der für all diese anderen Plattformen benötigt wird. Etwas wie das hier:

{
  "global": {
    "type": "token",
    "category": "typography"
  },
  "aliases": {
    "TYPE_SIZE_SM": {
      "value": "14px"
    },
    "TYPE_SIZE_MD": {
      "value": "25px"
    },
    "TYPE_SIZE_LG": {
      "value": "44px"
    }
  },

Sie könnten Ihren eigenen Code schreiben, um diese JSON-Datei zu nehmen und sie in alle benötigten Variablen umzuwandeln, z. B. würde eine Sass-Datei von diesen Tokens abhängen und sie als Variablen konsumieren, die an anderer Stelle in einer Web-App verwendet werden. Ein Beispiel für ein Tool, das viel Arbeit für uns erledigen kann, ist Amazons Style Dictionary, und hier ist ein Beispiel dafür, wie das in der Praxis funktioniert:

Ich finde das unglaublich raffiniert. Und ich kann sehen, wie es eine Menge doppelten Code und Verwirrung über mehrere Teams hinweg spart, da es als einzige Quelle der Wahrheit dient und nicht mehrere Codebasen mit denselben Designanforderungen und eigenen Stylesheets, die gepflegt werden müssen. Cristiano Rastelli schrieb auch vor einiger Zeit über das Verwalten von Design Tokens mit Style Dictionary und geht viel tiefer darauf ein, wie man anfängt.

Ihre Quelle der Wahrheit muss nicht einmal eine JSON-Datei sein! In einem Beitrag von Anfang dieses Jahres zeigt uns Pavel Laptev, wie man diese Design Tokens in Figma erstellt und durch die Verwendung ihrer API diese Werte aus Design-Mockups abstrahiert und in einer Codebasis verwendet.

Pavel hat sein Figma-Dokument in separate Seiten für sein Raster, Spacer, Palette und Typografie unterteilt, so:

Im Moment scheint dies viel Aufwand für die Einrichtung zu erfordern, aber ich schätze, dass Tools wie Sketch und Figma solche Dinge in naher Zukunft für uns viel einfacher machen werden – sie möchten wahrscheinlich, dass die Quelle der Wahrheit in ihrem spezifischen Designtool liegt und nicht in einem anderen Tool.

Das Letzte, was ich erwähnen möchte, ist dieser Beitrag von Brent Jackson, in dem er einige Gedanken zur Interoperabilität im Zusammenhang mit Designsystemen aufgeschrieben hat. Insbesondere argumentiert er, dass es eine Spezifikation für Design Tokens geben sollte, damit jede CSS-in-JS-Bibliothek diesen Code in jedem Format oder Stil konsumieren kann.

Designsystem-Tokens sollen flexibel und plattformübergreifend sein, was bedeutet, dass verschiedene Teams, Implementierungen und Bibliotheken Dinge unterschiedlich benennen werden. Hier würde diese Spezifikation passen. Viel Interoperabilität könnte erreicht werden, wenn wir zum Beispiel alle unsere Farbpalette colors und die verwendeten Schriftgrößen fontSizes nennen. Was Sie darüber hinaus tun und welches Datenformat Sie zur Speicherung dieser Werte verwenden, bleibt Ihnen überlassen. Es ist trivial, JSON in ES-Module, YAML oder sogar TOML zu konvertieren, wenn das Ihr Ding ist. Es ist auch nur eine Datenstruktur, sodass die Transformation zwischen anderen Datenstrukturen (z. B. Design-Tools oder einer GraphQL-API) ebenfalls möglich sein sollte. Dieser Standard würde auch nicht versuchen, die extrem komplexen Probleme der Benennung der Farben selbst zu lösen.

Brent hat dann eine Theme-Spezifikation erstellt, um genau dieses Problem zu lösen. Es scheint, dass ein einziger Standard für das Schreiben all unserer Variablen und Einstellungen uns helfen würde, wenn wir von einer CSS-in-JS-Bibliothek zu einer anderen wechseln wollten oder zu einem anderen System, das wir uns noch nicht vorgestellt haben.

Auf jeden Fall glaube ich, dass Design Tokens erst jetzt mainstream werden und ihre Popularität zunehmen wird, wenn diese Tools, Workflows und Standards mit der Zeit besser werden – das ist alles sehr aufregend!