Sl Ds: Lightning Design System Guide | SalesforceTutorial

Sl ds usually means SLDS, the Salesforce Lightning Design System. In Salesforce projects, SLDS gives admins, developers, and architects a shared system of patterns, CSS classes, component blueprints, accessibility guidance, and styling hooks for custom interfaces that still feel like Salesforce.

This article uses the search phrase sl ds where useful, but the official term is SLDS. A good sl ds implementation starts with standard Salesforce configuration and base Lightning components before custom markup.

Use sl ds when a standard record page, Dynamic Form, screen flow, or Lightning App Builder layout cannot meet the user need. The goal of sl ds is to keep custom UI consistent, accessible, and maintainable instead of creating a separate design language for each project.

What is sl ds in Salesforce?

sl ds is a common search variation for SLDS. Salesforce documents SLDS as the design system used to align custom interfaces with Lightning Experience. The official starting point is Salesforce Lightning Design System documentation.

In enterprise orgs, SLDS matters because one custom screen rarely lives alone. A console widget, a service case helper, a partner portal page, and a Visualforce migration page may all be used by the same teams. If spacing, button states, empty states, and error messages differ across each page, support cost rises and user confidence drops.

How lightning design fits Salesforce implementation work

Lightning design is not only CSS. It covers layout, hierarchy, interaction, accessibility, and language. In Salesforce, those decisions appear in page headers, cards, forms, buttons, tables, modals, tabs, validation messages, and empty states.

A practical architecture rule is to use declarative features before code. Try Lightning App Builder, Dynamic Forms, screen flows, standard related lists, and base components first. Move to raw SLDS markup only when the standard component model cannot represent the required user task.

Salesforce Lightning Design System resources developers use

The salesforce lightning design system gives teams patterns and guidelines, component blueprints, utility classes, and styling hooks. Patterns explain when an interaction should be used. Blueprints provide framework-neutral HTML and CSS. Utilities handle spacing, alignment, text, sizing, and visibility. Styling hooks help components adapt to supported Salesforce themes without hard-coded values.

Salesforce Trailhead explains the SLDS building blocks, including design tokens, utilities, guidelines, and component blueprints. Salesforce also documents that SLDS 2 was introduced in Spring ’25, while the original system is now called SLDS 1. That distinction matters when you work with styling hooks, themes, and the Salesforce Cosmos theme.

Where to use SLDS Salesforce patterns

The phrase slds salesforce and the related search sl ds usually appear when teams want to apply Salesforce styling in a specific technology. The right approach depends on where the UI runs.

How to use SLDS in Lightning Web Components

In LWC, the safest sl ds path is to use lightning-* base components. Salesforce states that base components in the lightning namespace use Salesforce Lightning Design System styling and add behavior, attributes, events, and methods on top of SLDS blueprints. See Style Components with Lightning Design System.

The sl ds example below uses base components for the card and buttons, then uses SLDS utility classes for spacing. It does not call Apex, so there are no Apex governor limits here. If you add Apex later, bulkify the server-side code and enforce CRUD/FLS before reading or updating records.

<template>
  <lightning-card title='Account Actions' icon-name='standard:account'>
    <div class='slds-p-around_medium'>
      <p class='slds-text-body_regular slds-m-bottom_small'>
        Review the current account before escalation.
      </p>
      <lightning-button-group>
        <lightning-button label='Review' variant='neutral' onclick={handleReview}></lightning-button>
        <lightning-button label='Escalate' variant='brand' onclick={handleEscalate}></lightning-button>
      </lightning-button-group>
    </div>
  </lightning-card>
</template>

import { LightningElement, api } from 'lwc';
import { ShowToastEvent } from 'lightning/platformShowToastEvent';

export default class AccountActionPanel extends LightningElement {
  @api recordId;

  handleReview() {
    this.notify('Review started', 'Account ' + this.recordId + ' is ready for review.', 'info');
  }

  handleEscalate() {
    this.notify('Escalation queued', 'Follow your org approval policy before changing ownership.', 'warning');
  }

  notify(title, message, variant) {
    this.dispatchEvent(new ShowToastEvent({ title, message, variant }));
  }
}

Slds button choices in LWC

For an slds button in LWC, or any sl ds button pattern, prefer <lightning-button> when the button performs a normal UI action. Use raw SLDS button markup only when a base component cannot meet the design or semantic requirement.

<lightning-button label='Save' variant='brand' onclick={handleSave}></lightning-button>

<button class='slds-button slds-button_brand' type='button' onclick={handleSave}>
  Save
</button>

Do not override internal selectors such as .slds-button_brand globally. Salesforce warns that overriding SLDS selectors can break when SLDS changes. Use documented variants, custom CSS properties, or supported styling hooks instead.

When to build from a component blueprint

For sl ds blueprint work, Salesforce documentation says to check available base components and styling hooks before building from an SLDS blueprint. A blueprint is static HTML and CSS. It does not provide data loading, validation, keyboard behavior, or record security by itself.

• Use a blueprint only when no base Lightning component covers the interaction.
• Confirm the pattern with UX and accessibility stakeholders.
• Add keyboard support and screen reader text where the pattern requires it.
• Own regression testing after seasonal Salesforce releases.

How to use SLDS in Visualforce

Visualforce pages can use sl ds when a legacy page must align with Lightning Experience. Salesforce documents the <apex:slds /> component for this purpose: apex:slds Visualforce Developer Guide.

<apex:page standardController='Account' applyBodyTag='false'>
  <head>
    <apex:slds />
  </head>
  <body class='slds-scope'>
    <div class='slds-card slds-p-around_medium'>
      <header class='slds-card__header slds-grid'>
        <h2 class='slds-card__header-title'>Account Review</h2>
      </header>
      <div class='slds-card__body slds-card__body_inner'>
        <p>Account Name: {!Account.Name}</p>
        <button class='slds-button slds-button_brand' type='button'>Start Review</button>
      </div>
    </div>
  </body>
</apex:page>

For sl ds Visualforce work, do not assume that adding <apex:slds /> converts every Visualforce component into a Lightning component. Review the rendered HTML, test in Lightning Experience, and confirm that controller code still respects sharing, CRUD, and field-level security.

SLDS 1, SLDS 2, and styling hooks in 2026

Salesforce now documents two sl ds versions. SLDS 1 is the original CSS framework. SLDS 2, introduced in Spring ’25, uses a newer architecture that separates structure from visual design through styling hooks. Salesforce documentation also notes that older design tokens still work in SLDS 1 themes, while SLDS 2 moves toward CSS custom variables and global styling hooks.

1. Use a base Lightning component and supported attributes.
2. Use documented SLDS utility classes for layout and spacing.
3. Use supported styling hooks or CSS custom properties for approved custom styling.
4. Build from an SLDS blueprint only when no base component fits.

This sequence keeps your UI closer to the platform and lowers release risk. For broader UI planning, see our Salesforce customization guide and Lightning Web Components tutorial.

Accessibility and testing checklist for SLDS Salesforce work

sl ds gives you an accessible starting point, but it does not automatically make every custom screen accessible. A custom modal, datatable action, lookup, or upload screen still needs semantic HTML, focus management, labels, error messaging, and keyboard testing.

• Use real <button> elements for actions, not clickable <div> elements.
• Provide visible labels or assistive text for icon-only actions.
• Do not remove focus outlines unless you replace them with an accessible focus indicator.
• Test tab order in console apps and Experience Cloud pages.
• Validate color contrast when using brand colors or custom themes.

In regulated orgs, include sl ds review in the definition of done. UI code can pass unit tests and still fail a release if screen reader behavior, focus order, or responsive layout breaks for a high-volume service team.

Common errors with SLDS implementation

Using CSS classes instead of base components

A raw sl ds class gives you styling, not component behavior. For example, slds-button does not provide the same API as lightning-button. Use base components when you need Salesforce-supported behavior and events.

Forgetting security when UI looks complete

sl ds does not enforce CRUD, FLS, row-level sharing, or Apex sharing rules. A polished page can still expose fields the user should not see if the data layer is wrong. In Apex controllers, use sharing rules intentionally and enforce field access. In LWC data access, prefer Lightning Data Service or UI API patterns where they fit.

Skipping release regression tests

Salesforce seasonal releases can change UI behavior. Keep a short sl ds regression checklist for button states, focus order, mobile layout, empty states, validation messages, modals, and table overflow.

Best practices for production SLDS work

• Start with user task flow. Do not copy a visual pattern unless it supports the action users need to complete.
• Prefer standard Salesforce components. Base Lightning components reduce custom JavaScript and accessibility work.
• Keep custom CSS local. In LWC, component CSS is scoped. Avoid global overrides that affect unrelated pages.
• Document non-standard UI decisions. Future admins and developers need to know why a blueprint was used instead of a base component.
• Test with real profiles and permission sets. UI layout, field visibility, and record access can change what the user sees.
• Use developer tooling. For front-end inspection workflows, see our Salesforce Chrome extension guide.

Frequently Asked Questions