SLDS 2: Salesforce rebuilt its design system for agents

SLDS 1 launched in 2015 and, as Salesforce puts it, set the standard for enterprise design at the time. It is a CSS framework: import it, use its classes, and your custom Lightning web components look like Lightning Experience. That is exactly what an enterprise platform wanted in 2015, when the goal was consistency across thousands of orgs and the assumption was that consistency meant sameness.

The stated reason for the rebuild is that two things changed. Customer demand for deeper customisation grew, and generative AI began reshaping user experiences. Both pressures point the same direction: a framework whose visual decisions are baked into its class definitions cannot be deeply themed and cannot be a stable target for generated UI.

That is a fairly bracing thing for a vendor to publish about its own decade-old flagship system. It is also correct, and the same diagnosis applies to a great many internal design systems that have not had it stated out loud.

The architectural claim is specific: the new CSS architecture is decoupled from Salesforce's default visual style, which means you are no longer locked into predefined design choices for components including buttons, modals, fonts and borders. The mechanism is global styling hooks — CSS custom properties — replacing hard-coded values inside the framework's rules.

The line Salesforce uses for the benefit is worth quoting as a design principle: one change updates everything. Instead of tweaking components individually, styling hooks let you adjust values in a single place for instant global updates.

Around the architecture sit the visible changes. Salesforce Cosmos is the new default theme for SLDS 2, described as offering adaptable spacing, at-a-glance views, an enriched colour palette, a reader-friendly typography scale and reduced cognitive load. The expanded Themes and Branding feature in Setup lets administrators apply brand colours, logos and images without code, with nine new accent colour options.

The no-code/pro-code split is deliberate and stated: admins get click-based design, designers and developers get pro-code control through the styling hooks. That is a real design-system governance decision — deciding which audience gets which surface — and most systems only ever build the pro-code half.

One detail deserves separating out because it solves a problem nearly every design system has and nearly none solves properly. The SLDS 2 Figma library uses the same semantic naming convention for styling hooks as the code does — Salesforce's own examples are radius-border-4 and font-scale-4 — so designs map one-to-one to live code.

The stated effect is a shared vocabulary bridging design and development. The practical effect is that a design handoff stops being a translation exercise. When a designer says font-scale-4 and the developer types font-scale-4, the entire category of "which grey did you mean" disappears.

The library also contains all the variables and properties you can toggle, so components can be modified in Figma directly rather than by switching between the documentation site and the design file and updating components one by one. That is a small tooling detail with a large behavioural consequence: it removes the friction that causes designers to go off-system.

SLDS 2 ships tooling that validates components against SLDS rules rather than describing them. SLDS Linter is the code analysis tool; SLDS Validator scans markup, validates it against a database, and offers recommendations for fixes. Salesforce lists new rule sets, in-line guidance and bulk linting.

This is the same instinct as Stripe's app UI toolkit refusing arbitrary CSS, reached by a different route. Stripe removes the capability; Salesforce cannot, because SLDS is CSS in a customer's org and the customer can always write more CSS. So it does the next best thing and makes violations visible mechanically.

Most teams only ever attempt the first row. The middle row is where the return on effort is highest, and it is unglamorous enough that it rarely gets prioritised until someone counts how many hex values are in the codebase.

Salesforce's description of SLDS 2 is direct: it is the foundation for the agentic design system for Salesforce products built on the Lightning Platform. The blog announcing it says the new architecture sets the foundation for agentic experiences and dark mode, and describes reimagining how design systems work both within the design-development workflow and within dynamically generated user experiences.

That last phrase is the one to sit with. Dynamically generated user experiences. Not "AI helps developers write code faster" — the interface itself is assembled at runtime, per user, per context, by something that was not a designer.

If that is your assumption, a design system that bakes appearance into component definitions is structurally unable to serve it, because the generator has nothing to vary. What a generated interface needs is exactly what SLDS 2 provides: a stable structural vocabulary with the visual decisions exposed as named, settable values.

SLDS 2 is not an isolated case. Three of the largest openly published enterprise design systems restructured within roughly eighteen months, each betting differently on the same premise.

Nobody coordinated this. Three companies with different products and different constraints arrived at compatible conclusions in the same window, which is usually a sign that the underlying change is real rather than fashionable.

The SLDS 2 architecture is a large, specific answer to a question most teams have not asked yet: can something other than a designer produce an on-brand interface from your design system? Four things transfer regardless of platform.

1. 1

   Separate structure from appearance

   Every visual decision that is currently a literal value inside a component rule is a decision a generator cannot vary and a customer cannot theme. Hoist them into named custom properties. This is unglamorous refactoring with a large payoff, and it is also the prerequisite for dark mode.

2. 2

   Name hooks semantically, and use the same names in the design tool

   radius-border-4 in Figma and radius-border-4 in CSS. One vocabulary, two renderings. Every mismatch between design-tool names and code names is a translation step where meaning leaks out.

3. 3

   Enforce mechanically, not editorially

   A linter that flags a raw hex value in a pull request does more for consistency than any amount of documentation. If you cannot build a rule database, start with a single rule banning literal colour values outside the token file.

4. 4

   Decide what the no-code surface is

   Salesforce split it explicitly: admins theme with clicks, developers theme with hooks. If your system has non-developer stakeholders who need to change something, giving them a bounded surface is how you stop them from asking for one-off overrides.

There is a fifth thing SLDS 2 does not cover, and it is the one most teams need most. Styling hooks tell a generator what can vary. They do not tell it what the right values are, what each role means, or what is forbidden.

We sampled 299 DESIGN.md files written to give AI agents exactly that guidance. 86% specified colours as raw hex with no semantic role, 76% contained no prohibitions of any kind, 69% said nothing about dark mode, and 57% defined no motifs. A generator handed a set of hooks and that file has an empty theming API and no argument about what to put in it.

Salesforce is explicit that switching is not required and that orgs can adopt at their own pace. The SLDS 2 site carries a Transition to SLDS 2 guidebook, and SLDS 1 documentation now lives at v1.lightningdesignsystem.com rather than the main domain — worth knowing if you have bookmarks or links in internal documentation pointing at the old URLs.

If you maintain custom Lightning web components, the linter is the sensible starting point regardless of when you migrate: run it, see how much of your CSS is asserting things the framework is about to stop asserting, and use that number to size the work honestly.