Tessera — ein Design System für Figma, Code und KI

Das Meeting, das ich verloren habe

Vor einiger Zeit sass ich in einem Meeting mit einer Firma in Zürich. Ihr Produkt läuft auf dem Desktop, auf dem Tablet und auf dem Handy, und sie fragten mich, was damit nicht stimmt. Ich sagte es so höflich, wie ich konnte: Es sieht aus wie zwei Produkte, weil euer Design System schwach ist, oder weil ihr keins habt.

Ich bekam das Projekt nicht. Ein Jahr später erzählte mir ein Freund, der dort arbeitet, dass sie jemanden eingestellt hatten, um ihr Design System zu reparieren.

An dieses Meeting denke ich bis heute. Niemand in diesem Raum hatte einen schlechten Button gestaltet. Das Problem lag dort, wo niemand hinschaute, und genau dort brechen Design Systems meistens. Mit diesem Problem beschäftige ich mich seit Jahren. Tessera ist die zwölfte Version des Design Systems, das ich in jedem Kundenprojekt einsetze. Die erste war ein UI-Kit in Adobe XD, die Marke kam aus Illustrator. Die zweite entstand in Figma. Jedes Mal, wenn sich das Fundament ändern musste, habe ich neu angefangen.

Wo Systeme brechen

Ein Design System scheitert selten, weil etwas schlecht aussieht. Es scheitert wie Karies. Von aussen bleibt der Zahn weiss, innen geht er kaputt, und wenn es endlich wehtut, sagt jemand im Meeting „Design System V2“.

Die Ursache liegt fast immer darin, wie das Team arbeitet. Ich habe gesehen, wie eine Führungsperson das System als Projekt für eine Woche behandelt und es einer Produktdesignerin als Zweitjob gibt. Die Sandbox-Seite für Experimente wurde langsam zur einzigen Quelle der Wahrheit, weil niemand das System besass und niemand wusste, wie eine Änderung hineinkommt.

Eine meiner Studentinnen kam in ein Team, das nicht wusste, dass es kein Design System hatte. Ihr Lead bat sie, das alte bis Ende Woche zu reparieren und danach ein neues zu beginnen. Ich stellte ihr zwei Fragen. Steht ein Launch an? Nein. Kommt ein neues Feature? Nein. Die Eile hatte also keinen Grund, und wenn das neue System fertig ist, passiert ihm dasselbe, weil sich die Arbeitsweise des Teams nicht geändert hat.

Nimm ein einfaches Benutzermenü. Jede Farbe, jeder Abstand und jede Linie darin ist ein Token, eine Entscheidung mit einem Namen. Liegen diese Entscheidungen an einem Ort, sieht das Menü überall gleich aus. Liegen sie in den Köpfen der Leute, entstehen zwei Produkte.

Dann kam ein dritter Ort dazu

Jahrelang lebte ein Design System an zwei Orten, in Figma und im Code, und schon diese beiden gleich zu halten war der schwierige Teil. Dann begannen meine Studierenden, mit Claude zu bauen. Sie zeigten mir Screens aus Claude Artifacts mit Komponenten, die ich weder in Figma noch im Code fand. Ich fragte, wie diese Arbeit zu den Entwicklern kommt. Niemand wusste es so richtig.

Die Engineering-Teams von Monday.com und PayPal beschreiben dasselbe. Der Assistent ignoriert die Komponenten und schreibt Farben fest in den Code, und weil die Vermutung kompiliert, kommt sie durchs Review. Ich arbeite jeden Tag mit Claude und gebe nicht dem Werkzeug die Schuld. Niemand hat ihm gesagt, was es gibt, also hat es geraten.

Zähl die Orte, die eine Design-Entscheidung heute erreichen muss: die Marke, Figma, GitHub, die Doku, React, Next.js, die Anwendung, die Website, ein KI-Agent, seine Artifacts und das Marketing. Elf Orte, und jeder hat seine eigene Kopie der Regeln. Die Frage, die ich mir immer wieder stellte, war also: Wie hält ein kleines Team all das auf einem System, wenn niemand Zeit hat, jeden Wert zu prüfen, und die nächste Person, die daran arbeitet, mich nie getroffen hat?

Regeln, die den Build stoppen

Ich habe aufgehört, Dokumenten zu vertrauen. Eine Regel, die nur in einem Dokument steht, verwässert. Also wurde jede Regel, die mir wichtig ist, zu einer Prüfung, und der Build stoppt, wenn etwas eine davon bricht.

Es beginnt in Figma, dann in einer Datei

Die Marke speist Figma, und in Figma wird das Design System entschieden. Von dort geht jede Farbe, jede Grösse, jeder Abstand, jeder Schatten und jede Dauer in Token-Dateien mit denselben Namen wie die Figma-Variablen. Ein Befehl macht daraus CSS. Zwei Prüfungen stoppen den Build: eine, wenn das CSS nicht mehr zu den Tokens passt, eine, wenn eine Komponente einen festen Wert benutzt. Bevor etwas live geht, prüfen Claude und ich ausserdem, dass Figma, der Code und GitHub noch übereinstimmen.

Dieselben Wörter auf beiden Seiten

In Figma wählt eine Designerin variant=brand. In React schreibt ein Entwickler variant="brand". Niemand muss zwischen den beiden übersetzen.

Gemessen, nicht geschätzt

Eine Diagramm-Palette in meinem früheren System hatte auf Weiss einen Kontrast von 2.5:1, weit unter dem, was Menschen brauchen, um die Farben zu unterscheiden. Ich habe sie ersetzt. Seitdem ist kein Farbpaar fertig, bevor ich sein Verhältnis berechnet habe: 4.5:1 für Text und 3:1 für Grafiken, die etwas bedeuten, im hellen und im dunklen Modus.

Dem Agenten sagen, was es gibt

Das war meine Antwort auf das, was ich bei meinen Studierenden sah. Tessera kommt mit einem Claude-Paket, ein paar Dateien, die man in ein Projekt kopiert. CLAUDE.md enthält zehn Regeln in einfachen Worten: zuerst die Komponenten verwenden, bevor man Markup schreibt, Tokens statt fester Werte, Farben nach Bedeutung wählen, Geldbeträge rechtsbündig, und wenn etwas fehlt, das sagen, statt es zu umgehen.

Eine Spec-Datei listet jede Komponente und jede Prop auf, damit der Agent keine erfindet, und vollständige Beispiel-Screens geben ihm etwas Echtes zum Nachbauen. Danach prüft ein Lint das Ergebnis. Schreibt der Agent eine feste Hex-Farbe, schlägt die Prüfung fehl und zeigt auf die Zeile. Ich kann einen Agenten nicht dazu bringen, sich zu benehmen, aber ich kann sichtbar machen, wenn er es nicht tut.

Eine Änderung, jeder Ort

Weil jeder Ort dieselben Tokens liest, passiert ein Rebranding nur einmal. Im Playground wählst du eine Markenfarbe, hell oder dunkel und eine Eckenform, und echte Komponenten folgen.

Neun Screens als Beweis

Ich habe neun vollständige Screens nur aus dem System gebaut, darunter ein Transaktionsjournal, ein Finanz-Dashboard und Kontoeinstellungen. Wenn ein Screen etwas brauchte, das dem System fehlte, habe ich das System geändert.

Wo es heute steht

Tessera ist seit Oktober 2026 live. Das gibt es heute:

• Über 70 React-Komponenten, Atome inklusive.
• Über 1'660 Design Tokens, alle aus einer Quelle gebaut.
• 66 CSS-Dateien, und der Lint findet darin keine einzige feste Farbe, Grösse oder Dauer.
• 9 vollständige Screens, nur aus dem System gebaut.
• 14 Basis-Komponenten gratis in einem Kit in der Figma Community.
• Textkontrast von mindestens 4.5:1 in drei Marken-Themes, hell und dunkel.
• Drei Kunden haben es nach einem einzigen LinkedIn-Post gekauft. Ich sammle, was sie dazu sagen, und ergänze es hier.

• 70+ React-Komponenten Dokumentiert
• 1,660+ Design Tokens Eine Quelle
• 66 CSS-Dateien Keine festen Werte
• 9 Vollständige Screens Nur aus dem System

Das Ergebnis, das mir am wichtigsten ist, lässt sich schwerer zählen: ob ein Team ein Produkt ausliefert, das auf Desktop, Tablet und Handy wie ein einziges Produkt aussieht. Das ist wieder das Meeting in Zürich.

Nenn es, wie du willst

Es heisst Tessera, aber der Name ist nur der Anfang. Wenn du es kaufst, kannst du ihm deinen eigenen Namen geben. Ändere das Logo und die Primitives, und jede Komponente folgt: die Farben, die Ecken, die Diagramme, die Buttons. Es wird dein Design System, mit den Prüfungen schon eingebaut.

Eine kleine Banking-App, nur aus Tessera-Komponenten gebaut, zeigt es am besten. Gib ihr einen neuen Namen, wähle eine andere Markenfarbe und schärfere Ecken, und die ganze App ändert sich mit. Niemand fasst einen einzigen Screen an.

Was ich noch nicht weiss

Zwölf Versionen haben mich gelehrt, dass ein Design System ein Produkt ist. Es braucht jemanden, dem es gehört, eine Roadmap und einen klaren Weg, wie Änderungen hineinkommen, sonst sterben selbst die besten Komponenten leise. Dokumentation allein reicht nicht. Menschen, und jetzt auch Agenten, folgen dem, was geprüft wird.

Jahrelang ging der Weg in eine Richtung, von Figma in die Produktion. Jetzt gibt es eine neue Schicht in der Mitte. Ein Agent kann einen funktionierenden Screen bauen, bevor jemand Figma öffnet, und dieser Screen fliesst zurück in Figma und ins Dev-Team. Darum frage ich mich, ob wir Figma nächstes Jahr noch brauchen. Meine Vermutung: ja, mit einer kleineren Aufgabe. Figma wird der Ort, an dem ein Team entscheidet, was das System ist, während mehr Screens anderswo entstehen. Sicher bin ich noch nicht.

Einige Fragen sind für mich noch offen. Wie viel darf ein Agent erfinden, bevor er fragen muss? Wenn eine Studentin in einem Claude Artifact eine gute Komponente baut, was ist der ehrliche Weg für sie nach Figma und in den Code? Wie streng darf ein System sein, bevor die Leute anfangen, es zu umgehen? Ganze Antworten habe ich noch nicht, und ich vermute, dass Version dreizehn mit einer davon beginnt.

Warum ich das schreibe

Ich gestalte Produkte und baue die Systeme dahinter, in Figma und im Code. Wenn dein Team ein Produkt ausliefert, das wie zwei aussieht, oder ein Design System hat, das niemand benutzt, würde ich gern davon hören. Schreib mir, es dauert eine Minute.

Wenn du genauer hinschauen willst: Da ist Tessera selbst, die Dokumentation, das kostenlose Figma-Kit und mein Guide zur Frage, ob man ein Design System selbst baut oder kauft.