Design Tokens so benennen, dass man sie auch in zwei Jahren noch nutzen kann

Eine Liste vor allem anderen

Das Register ist einfach eine geschriebene Liste aller Tokens im System, mit Name, Wert und einer kurzen Notiz, wofür er da ist. Wo es lebt, ist weniger wichtig, als dass es existiert. Es kann die erste Seite der Figma-Bibliothek sein oder der Einstieg in die eigene Präsentationsseite der Bibliothek. Wichtig ist, dass es vor den Komponenten kommt, denn die Komponenten werden daraus gebaut, und wer das System verstehen will, sollte das Vokabular vor den Sätzen kennenlernen.

Es ist verlockend, diesen Schritt zu überspringen und die Tokens still in Variablen und Code leben zu lassen. Dort funktionieren sie natürlich. Aber ein Token, den niemand liest, ist ein Token, den niemand wirklich lernt.

Durch Lesen lernt man es

Das Register ist nicht nur da, um zu existieren. Es ist da, um gelesen zu werden, und das Lesen macht es wirksam. Wenn Designer, Entwickler und Analysten die Liste durchgehen, setzt sich die Struktur der Namen im Gedächtnis fest: die Reihenfolge der Teile, die Bedeutung jedes Teils und die Logik, die sie verbindet. Nach einer Weile schlagen die Leute Namen nicht mehr nach, sondern sagen sie voraus, und genau darum geht es.

Deshalb verdient die Reihenfolge der Begriffe in einem Namen echte Sorgfalt. In meinen Systemen geht ein Name vom Allgemeinen zum Besonderen: erst die Kategorie, etwa Farbe oder Abstand, dann die Rolle, etwa Fläche, Text oder Rand, dann die Variante und zuletzt der Zustand, falls es einen gibt. Ein Name wie Farbe, Text, gedämpft, deaktiviert liest sich fast wie ein Satz, und wer die Grammatik kennt, kann den nächsten selbst bilden.

Bedeutung überlebt Werte

Die zweite Regel: nach Zweck benennen, nicht nach Aussehen. Ein Token namens Orange 500 nennt eine Farbe; ein Token namens Aktion, primär nennt eine Entscheidung. Ändert sich die Marke, wird das Orange vielleicht blau, aber die Entscheidung bleibt dieselbe, und jeder darauf gebaute Screen ändert sich korrekt, ohne dass jemand Dateien durchsucht. Rohe Werte gehören weiterhin ins System, liegen aber darunter, und man muss sie selten anfassen.

Was ohne eines passiert

Vor nicht allzu langer Zeit wurde ich zu einem Kunden mit einem riesigen System eingeladen, an das jeder Dienstleister andocken muss. Früh fragte ich so höflich wie möglich, ob sie zufällig ein Token-Register hätten. Die Antwort kam mit einem Seufzer: Nein, hätten sie nicht, aber eigentlich sollten sie. Ich musste ihnen ebenso behutsam sagen, dass es in der Bibliothek auch Namen gab, die schlicht falsch waren, und dass sich diese nicht mehr leicht aufräumen ließen, weil ein halbes Dutzend Teams und Dienstleister schon darauf gebaut hatte.

Niemand hatte einen dramatischen Fehler gemacht. Jeder Name schien dem, der ihn anlegte, an diesem Tag vernünftig. Was fehlte, war eine einzige geschriebene Liste, die alle lesen und die das Abdriften gezeigt hätte, lange bevor es zur Struktur wurde. Ein Register kostet am Anfang einen Nachmittag. Die Namen Jahre später zu entwirren, kostet Monate, und fertig wird man nie ganz.

Zwei Jahre später

Der echte Test eines Benennungsschemas kommt lange nach dem Launch, wenn neue Menschen dazukommen, neue Produkte hinzukommen und die ursprünglichen Autoren weitergezogen sind. Ein System mit einem klaren, lesbaren Register besteht diesen Test leise. Neue lernen die Sprache an einem Nachmittag, Namen bleiben konsistent, weil alle die Grammatik kennen, und die Tokens bedeuten weiter, was sie bedeuten sollten. Bei meinem letzten großen Projekt war das Register das Erste in der Bibliothek und auch die Seite, zu der die Leute am häufigsten zurückkehrten.