SLDS 2: Salesforce hat sein Designsystem für Agenten neu aufgebaut

SLDS 1 wurde 2015 eingeführt und setzte, wie Salesforce es formuliert, damals den Standard für Enterprise-Design. Es ist ein CSS-Framework: Man importiert es, nutzt die Klassen, und die eigenen Lightning Web Components sehen aus wie die Lightning Experience. Genau das war 2015 für eine Enterprise-Plattform gefragt, als das Ziel Konsistenz über Tausende von Orgs hinweg war und die Annahme galt, dass Konsistenz Gleichförmigkeit bedeutet.

Der genannte Grund für den Neuaufbau ist, dass sich zwei Dinge geändert haben: Die Kundennachfrage nach tiefergehender Anpassung ist gestiegen, und generative KI beginnt, User Experiences neu zu gestalten. Beide Faktoren weisen in dieselbe Richtung: Ein Framework, dessen visuelle Entscheidungen in den Klassendefinitionen festgeschrieben sind, kann nicht tiefgreifend themed werden und kann kein stabiles Ziel für generierte UIs sein.

Es ist ein recht schonungsloses Eingeständnis eines Anbieters über sein eigenes, zehn Jahre altes Flaggschiff-System. Es ist jedoch korrekt, und dieselbe Diagnose trifft auf viele interne Designsysteme zu, bei denen dies bisher nicht laut ausgesprochen wurde.

Die architektonische Behauptung ist spezifisch: Die neue CSS-Architektur ist vom Standard-Visual-Style von Salesforce entkoppelt. Das bedeutet, man ist nicht mehr an vordefinierte Designentscheidungen für Komponenten wie Buttons, Modals, Schriftarten und Rahmen gebunden. Der Mechanismus sind globale Styling Hooks – CSS Custom Properties –, die hartcodierte Werte innerhalb der Framework-Regeln ersetzen.

Der Satz, den Salesforce zur Beschreibung des Nutzens verwendet, ist als Designprinzip zitierwürdig: Eine Änderung aktualisiert alles. Anstatt Komponenten einzeln anzupassen, ermöglichen Styling-Hooks die Anpassung von Werten an einer einzigen Stelle für sofortige globale Aktualisierungen.

Um die Architektur herum liegen die sichtbaren Änderungen. Salesforce Cosmos ist das neue Standard-Theme für SLDS 2 und wird als ein Theme beschrieben, das anpassbare Abstände, Übersichtsansichten, eine erweiterte Farbpalette, eine leserfreundliche Typografie-Skala und eine reduzierte kognitive Belastung bietet. Die erweiterten Funktionen für Themes und Branding in Setup ermöglichen es Administratoren, Markenfarben, Logos und Bilder ohne Code anzuwenden, mit neun neuen Optionen für Akzentfarben.

Die Trennung zwischen No-Code und Pro-Code ist beabsichtigt und explizit formuliert: Administratoren erhalten klickbasiertes Design, Designer und Entwickler erhalten Pro-Code-Kontrolle durch die Styling-Hooks. Das ist eine echte Governance-Entscheidung für das Designsystem – die Entscheidung, welche Zielgruppe welche Oberfläche erhält – und die meisten Systeme bilden nur die Pro-Code-Hälfte ab.

Ein Detail verdient eine separate Betrachtung, da es ein Problem löst, das fast jedes Designsystem hat und das fast keines richtig löst. Die SLDS 2 Figma-Library verwendet dieselbe semantische Benennungskonvention für Styling-Hooks wie der Code – Salesforces eigene Beispiele sind radius-border-4 und font-scale-4 – sodass Designs eins zu eins auf den Live-Code abgebildet werden können.

Der genannte Effekt ist ein gemeinsames Vokabular, das Design und Entwicklung überbrückt. Der praktische Effekt ist, dass ein Design-Handoff aufhört, eine Übersetzungsübung zu sein. Wenn ein Designer font-scale-4 sagt und der Entwickler font-scale-4 tippt, verschwindet die gesamte Kategorie der Frage „Welches Grau meintest du?“.

Die Library enthält auch alle Variablen und Properties, die man umschalten kann, sodass Komponenten direkt in Figma geändert werden können, anstatt ständig zwischen der Dokumentationsseite und der Design-Datei zu wechseln und Komponenten einzeln zu aktualisieren. Das ist ein kleines Tooling-Detail mit großer Verhaltensfolge: Es entfernt die Reibung, die dazu führt, dass Designer das System verlassen.

SLDS 2 liefert Tooling, das Komponenten gegen SLDS-Regeln validiert, anstatt sie nur zu beschreiben. SLDS Linter ist das Code-Analyse-Tool; SLDS Validator scannt das Markup, validiert es gegen eine Datenbank und bietet Empfehlungen für Korrekturen. Salesforce listet neue Regelsätze, In-Line-Anleitungen und Bulk-Linting auf.

Dies ist derselbe Instinkt wie bei Stripe's app UI toolkit refusing arbitrary CSS, jedoch auf einem anderen Weg erreicht. Stripe entfernt die Möglichkeit; Salesforce kann das nicht, da SLDS CSS in der Organisation eines Kunden ist und der Kunde jederzeit mehr CSS schreiben kann. Also tut Salesforce das nächstbeste und macht Verstöße mechanisch sichtbar.

Die meisten Teams versuchen nur die erste Zeile. In der mittleren Zeile ist der Return on Effort am höchsten, und sie ist unglamourös genug, dass sie selten priorisiert wird, bis jemand zählt, wie viele Hex-Werte im Codebase vorhanden sind.

Salesforces Beschreibung von SLDS 2 ist direkt: Es ist das Fundament für das agentische Designsystem für Salesforce-Produkte, die auf der Lightning Platform aufgebaut sind. Der Blogpost zur Ankündigung besagt, dass die neue Architektur die Grundlage für agentische Erfahrungen und Dark Mode schafft, und beschreibt die Neugestaltung der Funktionsweise von Designsystemen sowohl innerhalb des Design-Entwicklungs-Workflows als auch innerhalb dynamisch generierter Benutzererfahrungen.

Dieser letzte Satz ist der entscheidende. Dynamisch generierte Benutzererfahrungen. Nicht „KI hilft Entwicklern, schneller Code zu schreiben“ – die Benutzeroberfläche selbst wird zur Laufzeit, pro Benutzer, pro Kontext, von etwas zusammengestellt, das kein Designer war.

Wenn dies Ihre Annahme ist, ist ein Designsystem, das das Erscheinungsbild fest in den Komponenten-Definitionen verankert, strukturell nicht in der Lage, dies zu bedienen, da der Generator nichts zu variieren hat. Was eine generierte Benutzeroberfläche benötigt, ist genau das, was SLDS 2 bietet: ein stabiles strukturelles Vokabular, bei dem die visuellen Entscheidungen als benannte, einstellbare Werte offengelegt werden.

SLDS 2 ist kein Einzelfall. Drei der größten, öffentlich zugänglichen Enterprise-Designsysteme wurden innerhalb von etwa achtzehn Monaten umstrukturiert, wobei jedes auf unterschiedliche Weise auf dieselbe Prämisse setzt.

Dies wurde nicht koordiniert. Drei Unternehmen mit unterschiedlichen Produkten und Einschränkungen kamen im selben Zeitraum zu kompatiblen Schlussfolgerungen. Das ist meist ein Zeichen dafür, dass die zugrunde liegende Änderung substanziell und nicht bloß ein Trend ist.

Die SLDS 2-Architektur ist eine umfassende, spezifische Antwort auf eine Frage, die sich die meisten Teams noch gar nicht gestellt haben: Kann jemand anderes als ein Designer eine markenkonforme Benutzeroberfläche aus Ihrem Designsystem erstellen? Vier Aspekte sind unabhängig von der Plattform übertragbar.

1. 1

   Struktur vom Erscheinungsbild trennen

   Jede visuelle Entscheidung, die derzeit als Literalwert innerhalb einer Komponenten-Regel steht, ist eine Entscheidung, die ein Generator nicht variieren und ein Kunde nicht thematisieren kann. Heben Sie diese in benannte Custom Properties.

2. 2

   Hooks semantisch benennen und dieselben Namen im Design-Tool verwenden

   radius-border-4 in Figma und radius-border-4 in CSS. Ein Vokabular, zwei Renderings. Jede Diskrepanz zwischen Namen im Design-Tool und Namen im Code ist ein Übersetzungsschritt, bei dem Bedeutung verloren geht.

3. 3

   Mechanisch erzwingen, nicht redaktionell

   Ein Linter, der einen rohen Hex-Wert in einem Pull Request markiert, leistet mehr für die Konsistenz als jede Menge an Dokumentation. Wenn Sie keine Regeldatenbank aufbauen können, beginnen Sie mit einer einzigen Regel, die Literal-Farbwerte außerhalb der Token-Datei verbietet.

4. 4

   Festlegen, was die No-Code-Oberfläche ist

   Salesforce hat dies explizit getrennt: Administratoren thematisieren per Klick, Entwickler über Hooks. Wenn Ihr System Stakeholder außerhalb der Entwicklung hat, die Änderungen vornehmen müssen, verhindern Sie durch eine abgegrenzte Oberfläche die Anfragen nach einmaligen Overrides.

Es gibt einen fünften Punkt, den SLDS 2 nicht abdeckt, und genau den benötigen die meisten Teams am dringendsten. Styling-Hooks sagen einem Generator, was variiert werden kann. Sie sagen ihm jedoch nicht, was die richtigen Werte sind, was die jeweilige Rolle bedeutet oder was verboten ist.

Wir haben 299 DESIGN.md-Dateien analysiert, die genau diese Anleitung für KI-Agenten liefern sollten. 86 % gaben Farben als rohen Hex-Wert ohne semantische Rolle an, 76 % enthielten keinerlei Verbote, 69 % erwähnten den Dark Mode nicht und 57 % definierten keine Motive. Ein Generator, dem ein Satz von Hooks und eine solche Datei übergeben wird, hat eine leere Theming-API und keine Grundlage dafür, was dort einzutragen ist.

Salesforce stellt explizit klar, dass ein Wechsel nicht erforderlich ist und Organisationen dies in ihrem eigenen Tempo adoptieren können. Die SLDS 2-Seite bietet einen Leitfaden für den Übergang zu SLDS 2 an, und die SLDS 1-Dokumentation befindet sich nun unter v1.lightningdesignsystem.com statt auf der Hauptdomain – wichtig zu wissen, falls Sie Lesezeichen oder Links in internen Dokumentationen zu den alten URLs haben.

Wenn Sie benutzerdefinierte Lightning Web Components pflegen, ist der Linter unabhängig vom Migrationszeitpunkt der sinnvollste Startpunkt: Lassen Sie ihn laufen, prüfen Sie, wie viel Ihres CSS Dinge definiert, die das Framework bald nicht mehr unterstützt, und nutzen Sie diesen Wert für eine ehrliche Aufwandsschätzung.