Overview
What problem does it solve?
SLDS creates a coherent Salesforce experience through base components, blueprints, utilities, themes, and platform conventions.
Primary focusCRM and enterprise workflows
System typePlatform design system
Notable strengthsEnterprise UI · Platform integration · Components
Official guidance
What the system documents
- SLDS 2 separates structure from visual styling through CSS custom properties called styling hooks.Supporting reference: SLDS version comparison
- Base Lightning components implement SLDS blueprints and automatically adapt to the active SLDS theme.Supporting reference: Base components
Analysis
Why this system is worth studying
Lightning is a useful case study in platform-bound design systems and architecture migration: current SLDS 2 guidance differs materially from legacy SLDS 1 token guidance.
Where another reference may help
Much of the implementation guidance is specific to Salesforce runtimes and org themes.
Consistent analysis model
System architecture at a glance
- Target environmentNot publicly documented
- Salesforce Lightning platformCompare this dimension
- Platform strategyNot publicly documented
- Framework-agnostic blueprints plus Lightning base componentsCompare this dimension
- FoundationsAnalysis
- Salesforce color, type, spacing, icons, themes, utilities, and platform styling architectureEvidence: SLDS version comparisonCompare this dimension
- Token maturityNot publicly documented
- SLDS 2 prioritizes global styling hooks; SLDS 1 design tokens are legacyCompare this dimension
- Component architectureAnalysis
- Blueprints describe framework-neutral structure; Lightning base components supply platform implementationEvidence: Base componentsCompare this dimension
- Interaction patternsAnalysis
- CRM records, data tables, forms, object actions, navigation, and enterprise feedbackEvidence: Base componentsCompare this dimension
- AccessibilityAnalysis
- Blueprints and base components provide a foundation while teams own complete flows and contentEvidence: Lightning Design SystemCompare this dimension
- Responsiveness / adaptivityAnalysis
- Grid, utility, and base-component behavior support Salesforce web and mobile contextsEvidence: Lightning Design SystemCompare this dimension
- Content guidanceAnalysis
- Salesforce terminology and product-writing decisions sit alongside platform conventionsEvidence: Lightning Design SystemCompare this dimension
- Documentation qualityAnalysis
- Strong implementation documentation, with important distinctions between SLDS 1 and SLDS 2Evidence: Lightning Design SystemCompare this dimension
- GovernanceAnalysis
- Salesforce maintains the platform, themes, components, and migration pathEvidence: Lightning Design SystemCompare this dimension
- Design-to-codeAnalysis
- Blueprint markup, styling hooks, Lightning base components, and platform toolingEvidence: Lightning Design SystemCompare this dimension
- Best learning valueNot publicly documented
- Platform integration and large-scale theming migrationCompare this dimension
- Notable tradeoffAnalysis
- Much of the implementation guidance is specific to Salesforce runtimes and org themes.Evidence: Lightning Design SystemCompare this dimension
What to study
Take these ideas into your own system
01Component blueprints
02Styling hooks
03Enterprise platform constraints
Primary references
Evidence and verification scope
Checked September 4, 2026: Official overview, foundations, components, accessibility, and implementation resources where publicly available. UXD Systems explains and compares; these sources remain the authority for current implementation details.
Source 1 · Official docs · checked September 4, 2026Lightning Design SystemSource 2 · Components · checked September 4, 2026Base componentsSource 3 · Foundations · checked September 4, 2026SLDS version comparison
Browse the complete source directory