Das Design System, das Nein sagt

“Soll die Karte 4px oder 8px Border-Radius haben?”

Ein 47-minütiger Thread. Vier Ingenieure, zwei Designer, eine Figma-Datei mit sechs Varianten. Die Diskussion umfasste iOS-Konventionen, Material-Design-Richtlinien, optische Ausrichtung und irgendwann sogar den Goldenen Schnitt. Niemand lag falsch. Genau das war das Problem.

Wir waren schon oft an diesem Punkt gewesen. Nicht nur beim Border-Radius — bei Verlaufsrichtungen, Shadow-Blur-Werten, Transparenzstufen für deaktivierte Zustände. Jede Entscheidung war klein. Jede Debatte war vernünftig. Und zusammengenommen fraßen sie unsere Geschwindigkeit auf.

Also hörten wir auf, die richtige Antwort zu finden. Wir eliminierten die Frage.

Die Kosten von Optionen

Jede visuelle Eigenschaft in einem Design System ist eine Entscheidungsfläche. Allein der Border-Radius wirft Fragen auf: Sollen Buttons und Karten denselben Wert verwenden? Was ist mit verschachtelten Elementen — wird der innere Radius vom äußeren abgezogen? Ändert sich der Radius bei verschiedenen Größen?

Keine dieser Fragen ist schwer. Genau das macht sie gefährlich. Sie sind leicht genug, dass jeder eine Meinung hat, aber unbedeutend genug, dass keine Meinung nachweislich besser ist. Klassisches Bikeshedding.

Wir haben PR-Kommentare über ein Quartal manuell getaggt. Rund 30 % unserer Design-System-Review-Threads drehten sich um kosmetische Werte ohne Auswirkung auf die Benutzerfreundlichkeit. Nicht Layout. Nicht Barrierefreiheit. Nicht Interaktionsmuster. Nur… Ästhetik.

Dann haben wir die Regeln geschrieben.

Warum Eliminieren statt Einschränken

Die naheliegende Alternative wäre, die Eigenschaften beizubehalten, aber zu begrenzen. Die meisten ausgereiften Design Systeme tun dies — drei erlaubte Border-Radius-Werte, eine Schatten-Abstufungsskala, eine kuratierte Farbverlauf-Palette. Wir haben es in Betracht gezogen.

Das Problem ist, dass eingeschränkte Optionen trotzdem Debatten erzeugen. “Soll diese Karte radius-sm oder radius-md verwenden?” ist dieselbe Diskussion mit weniger Antworten. Weniger ist besser als viele, aber null ist besser als weniger. Eine Eigenschaft einzuschränken reduziert Entscheidungen. Sie zu eliminieren entfernt die Entscheidung vollständig.

Wir haben auch Linting untersucht — eine ESLint-Regel, die nicht autorisierte Werte ablehnt. Aber ein Linter, der “nur 0, 4 oder 8px Radius verwenden” erzwingt, lässt immer noch drei Möglichkeiten offen. Das Ziel war nicht, die Entscheidung einfacher zu machen. Es war, sie überflüssig zu machen.

Vier Regeln

Beakets Komponentenbibliothek hat vier visuelle Einschränkungen:

1. Kein Border-Radius. Scharfe Ecken bei allem. Buttons, Karten, Eingabefelder, Dialoge, Tooltips — alles rechteckig.
2. Keine Farbverläufe. Nur flache Farben. Jede Oberfläche ist eine einzige CSS-Variable.
3. Keine Blur-Schatten. Kein box-shadow mit Blur-Radius. Nur Offset-Schatten.
4. Keine dekorative Transparenz. Deaktivierte Zustände verwenden Farbänderungen, keine Transparenz. Keine opacity: 0.5-Abkürzungen.

Das sind keine Richtlinien. Es sind harte Regeln, die im Code-Review durchgesetzt und in unseren Komponenten-Guidelines dokumentiert sind. Ein PR, der rounded-md hinzufügt, wird abgelehnt.

Warum genau diese vier Eigenschaften? Weil sie diejenigen waren, die die meisten Debatten bei der geringsten Auswirkung auf die Benutzerfreundlichkeit erzeugten. Abstände und Typografie beeinflussen die Lesbarkeit. Farbe beeinflusst die Bedeutung. Aber der Unterschied zwischen 4px und 8px Border-Radius? Zwischen einem 4px-Blur-Schatten und einem 6px-Blur-Schatten? Wir konnten keinen einzigen Fall finden, in dem diese Entscheidungen messbar beeinflussten, wie gut jemand das Produkt nutzen konnte.

Nach Einführung der Regeln bewegten sich unsere Design-System-PRs schneller. Review-Threads wurden kürzer. Designer produzierten keine mehrfachen Varianten derselben Komponente mehr, die sich nur in der Eckenbehandlung oder Schattentiefe unterschieden. Die Debatten nahmen nicht ab — sie verschwanden.

Was wir stattdessen verwenden

Optionen zu entfernen bedeutet nicht, visuelle Hierarchie zu entfernen. Man muss weiterhin Tiefe, Zustände und Interaktion kommunizieren. So haben wir jede Eigenschaft ersetzt.

Offset-Schatten statt Blur

Statt box-shadow: 0 4px 6px rgba(0,0,0,0.1) verwenden wir Hard-Offset-Schatten, die als CSS-Variablen definiert sind:

--shadow-offset: 1px 1px 0px 0px var(--color-chrome);
--shadow-offset-hover: 2px 2px 0px 0px var(--color-chrome);
--shadow-offset-active: 0px 0px 0px 0px var(--color-chrome);

Drei Interaktionszustände. Null Blur. Das ist das gesamte Schattensystem.

Der Standardzustand hat einen 1px-Offset — das Element sitzt leicht über der Oberfläche. Hover erhöht auf 2px — ein dezentes Anheben. Active springt auf 0px — das Element drückt sich flach. Es ist eine kleine, mechanische Animation, die Interaktion klar kommuniziert und dem Entwickler nichts zum Konfigurieren überlässt.

In der Praxis wendet jede interaktive Komponente dieselben drei Tokens an. Hier ist die Basis unserer Button-Komponente (vereinfacht aus dem vollständigen CVA-String, der auch deaktivierte und Fokus-Zustände enthält):

const buttonVariants = cva(
  [
    "inline-flex items-center justify-center gap-2",
    "font-medium cursor-pointer",
    "shadow-offset hover:shadow-offset-hover active:shadow-offset-active",
    "transition-shadow duration-100",
    // ... disabled, focus-visible, and icon styles
  ].join(" "),
  // ... variants
);

Keine Entscheidungen darüber, welche Schattenstufe eine Komponente “verdient.”

Flache Farben durch CSS-Variablen

Unsere Farbpalette — wir nennen sie “Porcelain” — hat 14 Neutraltöne von graphite (#030509) bis paper (#ffffff). Sie sind kalt und blaustichig. Die Theme-Beschreibung in unserer Dokumentation lautet: “Industrielle Präzision. Geätzt auf Bedienfelder in schwarzem Synthetiklack. Reines Weiß, kaltschwarze Tinte, geisterhafte Schatten, Teal-Akzent.”

Jede Farbreferenz läuft über ein semantisches Token:

--color-text-primary: var(--color-graphite);
--color-text-secondary: var(--color-steel);
--color-bg-primary: var(--color-paper);
--color-border-default: var(--color-chrome);

Wir vermeiden Tailwind-Farbstandards wie bg-white oder text-gray-500. Jede Farbe ist eine benannte Variable, und jede Variable wird einer Rolle zugeordnet. Niemand debattiert, ob etwas gray-100 oder gray-200 sein sollte — das semantische Token beantwortet die Frage bereits.

Scharfe Ecken überall

Hier ist kein Ersatz nötig. Man fügt einfach… keinen Border-Radius hinzu.

Was uns überraschte, ist, wie gut scharfe Ecken mit Offset-Schatten zusammenwirken. Eine abgerundete Karte mit einem Offset-Schatten sieht seltsam aus — die harte Kante des Schattens kollidiert mit der weichen Ecke. Aber eine scharfe Karte mit einem Offset-Schatten wirkt beabsichtigt. Die Geometrie ist konsistent. Die Einschränkungen verstärken sich gegenseitig auf Weisen, die wir nicht vollständig vorhergesehen hatten.

Die visuelle Sprache wird durch Subtraktion konsistent. Wenn alles scharf ist, muss nichts seine Form rechtfertigen.

Wo sich Einschränkungen potenzieren

Der größte Vorteil dieses Ansatzes zeigt sich bei übergreifenden Anliegen — den Mustern, die jede Komponente betreffen.

Deaktivierte Zustände sind berüchtigt inkonsistent über Komponentenbibliotheken hinweg. Manche verwenden Transparenz, manche ändern den Hintergrund, manche beides. Wir haben ein Muster, das auf jede Komponente angewendet wird:

disabled:shadow-none disabled:cursor-not-allowed disabled:border-dashed disabled:border-chrome disabled:bg-frost disabled:text-steel

Buttons, Eingabefelder, Selects, Checkboxen, Switches — alle identisch. Schatten entfernt (die interaktive Affordanz verschwindet), gestrichelter Rahmen, Frost-Hintergrund, Steel-Text. Wenn man eine deaktivierte Komponente gesehen hat, hat man alle gesehen. Die Einschränkungen beseitigten die Versuchung, deaktivierte Zustände an die “visuelle Persönlichkeit” jeder Komponente anzupassen. Wenn Komponenten keine visuelle Persönlichkeit haben, konvergieren deaktivierte Zustände von selbst.

Fokus-Ringe funktionieren genauso. Jede fokussierbare Komponente verwendet:

focus-visible:outline-2 focus-visible:outline-signal-blue focus-visible:outline-offset-2

Eine Farbe. Eine Breite. Ein Offset. Ein Tastaturnutzer, der durch ein Formular navigiert, sieht bei jedem Element genau denselben Ring. Keine Komponente überschreibt ihn. Keine Variante entfernt ihn. In Kombination mit dem einheitlichen Deaktiviert-Muster weiß ein Nutzer immer genau, wie “inaktiv” und “fokussiert” aussehen — unabhängig davon, mit welcher Komponente interagiert wird.

Die eine Ausnahme

Radio Buttons verwenden rounded-full.

Das ist es. Das ist die einzige Ausnahme in der gesamten Komponentenbibliothek. Sie ist in unseren Komponenten-Guidelines neben den Regeln dokumentiert, die sie bricht, denn selbst Ausnahmen sollten Entscheidungen sein, keine Zufälle.

Ein eckiger Radio Button würde Nutzer verwirren. Die runde Form ist so tief in Interface-Konventionen verankert, dass ihre Entfernung Benutzerfreundlichkeit für ästhetische Reinheit opfern würde. Wir entschieden, dass das ein schlechter Tausch war.

Man könnte fragen: Wenn die Benutzerfreundlichkeit eine Ausnahme für Radio Buttons rechtfertigt, warum nicht für Avatare, Tags oder Toggle-Switches? Wir haben es getestet. Eckige Avatare mit Offset-Schatten sehen aus wie Profilkarten — sie wirken beabsichtigt. Tags und Toggles sind weniger konventionsgebunden als Radio Buttons. Die Kreis-Affordanz ist einzigartig stark bei Radio Buttons; nichts anderes hat die Schwelle überschritten.

Das Ziel war nie “Brutalismus um des Brutalismus willen.” Es war, visuelle Entscheidungen zu eliminieren, die ihre Komplexität nicht rechtfertigen. Ein runder Radio Button verdient seine Form. Eine runde Karte nicht.

Was das wirklich kostet

Es wäre unehrlich zu behaupten, dass dieser Ansatz keine Nachteile hat. Die gibt es.

“Es sieht unfertig aus.” Das ist eine echte Reaktion aus Nutzertests. Scharfe Ecken und flache Farben signalisieren nicht denselben Feinschliff wie abgerundete, schattierte Interfaces. Wir mussten die Begründung mehr als einmal erklären.

Manche Komponenten wirken starr. Besonders Tooltips und Popovers sehen mit scharfen Ecken schwerer aus. Blur-Schatten existieren aus gutem Grund — sie erzeugen ein Schwebeeffekt, den Offset-Schatten nicht ganz replizieren können.

Drittanbieter-Komponenten brechen das Muster. Datumswähler, Rich-Text-Editoren, Diagrammbibliotheken — sie alle kommen mit eingebautem Border-Radius und Blur-Schatten. Wir überschreiben, was wir können, und akzeptieren gewisse Inkonsistenzen an den Rändern. Das ist eine andauernde Spannung, kein gelöstes Problem.

Designer-Ausdruck wird eingeschränkt. Wenn man der Typ Designer ist, der Freude am Gestalten von Mikrointeraktionen mit Verlaufs-Overlays und subtiler Tiefe findet, wird dieses System einschränkend wirken. Das ist der Sinn — aber es ist trotzdem ein realer Kostenpunkt für die kreative Zufriedenheit.

Es polarisiert. Manche Ingenieure lieben die Einfachheit. Andere halten es für dogmatisch. Wir haben diese Spannung nicht vollständig aufgelöst. Wir haben nur entschieden, dass der Konsistenzvorteil die ästhetischen Kosten für unser Produkt überwiegt.

Was wir noch nicht wissen

Wir haben dieses System noch nicht in echtem Maßstab getestet — Hunderte von Komponenten, datendichte Interfaces, Drittanbieter-Integrationen, die nativ aussehen müssen. Tabellen, Diagramme und Dashboards könnten Tiefenhinweise benötigen, die Offset-Schatten nicht liefern können.

Wir sind uns aufrichtig unsicher, ob Nutzer dasselbe intuitive Verständnis unserer Schattenzustände (Standard → Hover → Active) entwickeln, das sie mit konventionellen Elevations-Systemen haben. Wir haben keine Usability-Rückschritte beobachtet, aber wir haben dazu auch keinen formellen A/B-Test durchgeführt. Es funktioniert bisher. Aber “bisher” ist eine kleine Stichprobe.

Einschränkungen als Entscheidungen

Jede Einschränkung in diesem System ist eine Entscheidung, die einmal getroffen wurde, damit sie nicht erneut getroffen werden muss. Kein Border-Radius ist keine ästhetische Präferenz — es ist ein ADR (Architecture Decision Record) für die gesamte Komponentenbibliothek.

Wenn Ihr Team Zeit damit verbringt, über visuelle Eigenschaften zu debattieren, die die Benutzerfreundlichkeit nicht beeinflussen, erwägen Sie, die Option vollständig zu entfernen. Sie werden sie wahrscheinlich weniger vermissen, als Sie denken.