Unabhängige Analyse der öffentlichen Dokumentation und der Texte des Design-Teams von Salesforce. Identity Forge ist nicht mit Salesforce verbunden und wird nicht von diesem unterstützt. Salesforce, Lightning und Agentforce sind Marken ihres jeweiligen Eigentümers. Die Release-Details entsprechen der Dokumentation zum Zeitpunkt der Erstellung.
Das Problem von SLDS 1
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 gewünscht, als das Ziel Konsistenz über Tausende von Orgs hinweg war und man davon ausging, dass Konsistenz Gleichförmigkeit bedeutet.
Der genannte Grund für die Überarbeitung 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 gethemt 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.
Was SLDS 2 geändert hat
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.
| SLDS 1 | SLDS 2 | |
|---|---|---|
| Ort der visuellen Entscheidungen | Innerhalb der CSS-Regeln des Frameworks | In CSS Custom Properties, die man selbst definieren kann |
| Änderung eines Eckenradius überall | Override-Selektoren, Kampf mit der Spezifität, Hoffnung | Eine Custom Property setzen |
| Theming-Tiefe | Grob: Markenfarben und Logo | Buttons, Modals, Schriftarten, Rahmen, Abstände |
| Dark Mode | Nicht realisierbar | Der vorgegebene Weg in die Zukunft |
| Was das Framework vorgibt | Struktur und Erscheinungsbild | Struktur; das Erscheinungsbild wird bereitgestellt |
Der Satz, den Salesforce für den Nutzen 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.
Dieser Satz ist die Definition eines Token-Systems und der Test, den man auf das eigene anwenden sollte. Wenn die Änderung des Eckradius Ihrer Marke bedeutet, mehr als eine Stelle bearbeiten zu müssen, haben Sie Variablen, keine Design-Tokens. Der Unterschied liegt darin, ob der Wert ein einziges Zuhause oder viele Kopien hat.
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 kommuniziert: 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, bei der festgelegt wird, welche Zielgruppe welche Oberfläche erhält – die meisten Systeme bilden jedoch nur die Pro-Code-Hälfte ab.
Die Figma-Library, die exakt zum Code passt
Ein Detail verdient eine separate Betrachtung, da es ein Problem löst, das fast jedes Designsystem hat und das kaum eines richtig löst. Die SLDS 2 Figma-Library verwendet dieselbe semantische Benennungskonvention für Styling-Hooks wie der Code (radius-border-4 und font-scale-4 sind Beispiele von Salesforce selbst), 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 Sie umschalten können, 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 Designer dazu bringt, das System zu verlassen.
Wenn ein Designerfont-scale-4sagt und der Entwicklerfont-scale-4tippt, fällt eine ganze Kategorie von Handoff-Bugs weg.
Durchsetzung: der Linter
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 Korrekturvorschläge an. 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.
| Mechanismus | Kosten | |
|---|---|---|
| Dokumentation | Schreiben Sie auf, was korrekt ist, und hoffen Sie es | Kostenlos und etwa so effektiv wie kostenlos |
| Linting | Verstöße im Editor und in der CI markieren | Echte Tooling-Investition; erfordert eine Regel-Datenbank, die parallel zum System gepflegt wird |
| Entzug der Möglichkeit | Das Falsche unmöglich zu formulieren machen | Jeder echte neue Bedarf wird zu einer Anfrage an die Systembesitzer |
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 sich im Codebase befinden.
Der agentische Teil, in den Worten von Salesforce selbst
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 den 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, Code schneller zu schreiben“. Die Benutzeroberfläche selbst wird zur Laufzeit, pro Benutzer und 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.
Es ist bemerkenswert, wer dieses Argument vorbringt. Dies ist kein Startup, das KI-Design-Tools verkauft. Es ist ein Enterprise-Plattform-Anbieter mit einer jahrzehntelangen installierten Basis und jedem Anreiz, ein funktionierendes Framework nicht umzubauen – und veröffentlicht dennoch, dass er es trotzdem getan hat, und erklärt warum.
Derselbe Schachzug, dreimal
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.
| Was sich geändert hat | Die Wette | |
|---|---|---|
| Salesforce Lightning (SLDS 2) | CSS-Architektur entkoppelt vom visuellen Stil; Styling-Hooks; Linter und Validator | Struktur und Erscheinungsbild müssen getrennt werden, und Verstöße müssen mechanisch erkannt werden |
| IBM Carbon | Ein MCP-Server, der Dokumentationen und Code-Beispiele für Agenten bereitstellt | Agenten sollten das System zum Zeitpunkt der Generierung abrufen, anstatt es aus dem Gedächtnis zu reproduzieren |
| Shopify Polaris | React wurde durch framework-agnostische Web-Komponenten ersetzt, die über ein CDN bereitgestellt werden | Die Auslieferung darf keine Annahmen darüber treffen, was die Seite generiert hat |
Niemand hat dies koordiniert. Drei Unternehmen mit unterschiedlichen Produkten und Einschränkungen sind im selben Zeitraum zu kompatiblen Schlussfolgerungen gelangt – meist ein Zeichen dafür, dass die zugrunde liegende Änderung substanziell und nicht bloß ein Trend ist.
Was man daraus ziehen kann, wenn man Salesforce nicht nutzt
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
Struktur vom Erscheinungsbild trennen
Jede visuelle Entscheidung, die derzeit als Literalwert innerhalb einer Komponenten-Regel existiert, ist eine Entscheidung, die ein Generator nicht variieren und ein Kunde nicht themen kann. Heben Sie diese in benannte Custom Properties aus. Dies ist ein unspektakuläres Refactoring mit großem Nutzen und zudem die Voraussetzung für den Dark Mode.
- 2
Hooks semantisch benennen und dieselben Namen im Design-Tool verwenden
radius-border-4in Figma undradius-border-4in 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
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
Festlegen, was die No-Code-Oberfläche ist
Salesforce hat dies explizit getrennt: Administratoren themen per Klick, Entwickler themen über Hooks. Wenn Ihr System Stakeholder außerhalb der Entwicklung hat, die Änderungen vornehmen müssen, verhindern Sie durch eine abgegrenzte Oberfläche, dass diese Einzelanpassungen (Overrides) anfordern.
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.
Identity Forge Design-Kits sind genau diese Grundlage in einer für Agenten ausführbaren Form: semantische Farbrollen für Light- und Dark-Mode, Typografie- und Spacing-Skalen, Motive sowie explizite Do's und Don'ts, serialisiert in einer DESIGN.md. Kits durchsuchen oder lesen Sie, was eine DESIGN.md-Datei ist.
Praktische Hinweise zur Migration
Salesforce stellt explizit klar, dass ein Wechsel nicht erforderlich ist und Organisationen diesen in ihrem eigenen Tempo vollziehen 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 warten, ist der Linter unabhängig vom Migrationszeitpunkt der sinnvollste Startpunkt: Lassen Sie ihn laufen, prüfen Sie, wie viel Ihres CSS Dinge festlegt, die das Framework bald nicht mehr vorgibt, und nutzen Sie diesen Wert für eine ehrliche Aufwandsschätzung.
Was ist der Unterschied zwischen SLDS 1 und SLDS 2?
SLDS 1 ist ein CSS-Framework, in dessen Regeln die visuellen Entscheidungen von Salesforce fest integriert sind. SLDS 2 wird um CSS Custom Properties herum neu architektiert, sodass die Struktur erhalten bleibt und das Erscheinungsbild über Styling-Hooks bereitgestellt wird. Dies ermöglicht tiefgreifendes Theming sowie den Dark Mode und ist das, was Salesforce als Grundlage für agentische Experiences beschreibt.
Muss ich auf SLDS 2 migrieren?
Nein. Salesforce gibt an, dass ein Wechsel nicht erforderlich ist und Sie diesen in Ihrem eigenen Tempo vollziehen können. Die SLDS 2-Seite veröffentlicht einen Leitfaden für den Übergang zu SLDS 2, und die SLDS 1-Dokumentation bleibt unter v1.lightningdesignsystem.com verfügbar.
Was sind SLDS Styling-Hooks?
Vom Framework bereitgestellte CSS Custom Properties, mit denen Sie Werte wie Farbe, Radius und Typografie global festlegen können, anstatt Selektoren Komponente für Komponente zu überschreiben. Sie sind der Mechanismus, der die Architektur von SLDS 2 von seinem Standard-Erscheinungsbild entkoppelt.
Unterstützt SLDS 2 den Dark Mode?
Salesforce beschreibt den Weg zum Dark Mode als einen Prozess, der mit dem Übergang zu SLDS 2 beginnt. Die Custom-Property-Architektur ist die Voraussetzung. Prüfen Sie die aktuellen Release Notes für die tatsächlich implementierten Funktionen, da es sich hierbei um eine Roadmap-Aussage handelt, die sich ändern kann.
Was bedeutet "agentisches Designsystem" hier eigentlich?
Salesforce setzt es im Kontext der Agentforce-Plattform für Oberflächen ein, die dynamisch zusammengestellt statt bildschirmweise gestaltet werden. Strukturell bedeutet dies, dass das Designsystem seine visuellen Entscheidungen als benannte, setzbare Werte bereitstellen muss, da ein Generator, der eine Benutzeroberfläche zur Laufzeit erstellt, sowohl variable als auch fixierte Parameter benötigt.