You do not install SLDS inside Lightning Experience; the styles are already there. The setup work is applying it correctly in a custom Lightning Web Component and customizing the brand through styling hooks rather than overriding classes. Here is the practical flow.
- Start from a blueprint
Open lightningdesignsystem.com, find the pattern you need (button, card, modal, data table), and copy the documented markup with its SLDS classes into your component template.
- Prefer base components
Where a base lightning- component exists, use it instead of raw classes. A lightning-button with variant="brand" gives you a branded, accessible button with no SLDS class wiring.
- Customize with styling hooks
To change appearance, declare a CSS custom property in your component's stylesheet. Use a --slds-c- hook on the :host selector for one component, or a --slds-g- global color hook for an app-wide brand color.
- Validate the code
Install the SLDS Validator in VS Code, then run the SLDS Linter to flag deprecated design tokens and class overrides. Apply its automated fixes and re-run until the code is clean.
Changes one component only, like a thicker border on a single button; not yet supported in SLDS 2 themes.
Sets a value used across the whole app, such as a brand color; works in both SLDS 1 and SLDS 2 and helps meet WCAG 2.1 contrast.
Wraps an SLDS blueprint with built-in styling and accessibility; the fastest way to stay consistent without classes.
- Do not override SLDS classes with your own CSS; overrides break when SLDS updates ship. Use styling hooks instead.
- Design tokens (the --lwc- variables) work in SLDS 1 but are absent from SLDS 2. Replace them with global styling hooks.
- Component styling hooks (--slds-c-) are not yet supported in SLDS 2, so components that rely on them stay on SLDS 1 for now.
- Token and hook values resolve at compile time, so runtime CSS APIs like getPropertyValue will not read them.