Get Started with the Salesforce Lightning Design System (SLDS)
Learning Objectives
After completing this unit, you’ll be able to:
- Explain what a design system is.
- Articulate what SLDS is used for.
- Identify the four primary elements that comprise SLDS.
What’s a Design System?
First things first, let’s define design system so we’re all on the same page: A design system is a collection of repeatable design patterns and reusable code, referred to as components.
Design systems are like building blocks. They exist to help designers and developers build different experiences, and to do it cheaper, faster, and better than if they had to start from scratch with every new project. A good design system is scalable, efficient, visually cohesive, and shared—all of which make it perfect for organizations that need to build multiple products that share a common look and feel, and can be easily scaled to meet user demand.
That definition is taken from the Lightning Design System Basics Trailhead module, by the way. If you’re unfamiliar with the basics of design systems, and the Salesforce Lightning Design System (SLDS) in particular, that module is a great place to start.
But if you’re familiar with design systems, and ready to jump into developing with SLDS, you’re in the right place.
What’s the Salesforce Lightning Design System?
Here’s how we describe SLDS.
The Salesforce Lightning Design System includes the resources to create user interfaces consistent with Salesforce's user experience principles, design language, and best practices. Rather than focusing on pixels, developers can focus on application logic, while designers can focus on user experience, interactions, and flows.
In other words, SLDS is a design system created to make it easier for designers and developers to build great user experiences on the Salesforce platform. SLDS is designed to be a living design system: It’s open-source, and receives UI updates with every new release of the Salesforce platform.
One of the great things that makes SLDS stand out from other design systems is its implementation-agnostic approach. Implementation-agnostic is a fancy way of saying that you don’t have to adopt a specific framework in order to use SLDS. You can use SLDS with virtually any tech stack you like, including Salesforce technologies like Lightning Web Components, Aura, and Visualforce.
The Four Fundamentals
SLDS is made up of four fundamental elements: design tokens, utilities, guidelines, and component blueprints. Let’s take a look at each of the elements.
Design Tokens
Also known simply as tokens, design tokens are the heart and soul of a design system. It’s worth mentioning up front that a design token can be written in multiple ways depending on context.
- Like this in Lightning Web Components:
--lwc-brandAccessible - This in Aura:
t(brandAccessible) - Or this in Sass, a CSS preprocessor:
$brand-accessible
Think of design tokens as the atomic elements you can modify values with. They’re SLDS’s way of assigning a color or text attribute (font, font size, a few others) to a variable you can reuse in your project. You use tokens in place of hard-coded values to maintain a scalable and consistent visual system. For example, instead of using a hex value for color, you use a variable.
Here’s a short example in which three tokens can be used in a component to set background color, text color, and spacing values. When you begin authoring your component’s styles, instead of using hard-coded values, you reference a standard token or one of your own custom design tokens. Here, we create a class called .my-widget and reference three standard tokens. To learn about what tokens are available visit https://www.lightningdesignsystem.com/design-tokens/.
.my-widget {
background-color: var(--lwc-colorBackground);
color: var(--lwc-colorTextDefault);
margin: var(--lwc-spacingMedium);
}
See how .my-widget references the tokens as values in the component? Boom! Easy-peasy. Design tokens really become useful when a system grows in complexity. Imagine trying to keep your background colors in sync if you have hundreds of components each with hard-coded colors!
Need to change the background color of all three components? Just update the value of the background token. That single change trickles out to all the components referencing it and updates their values automatically. Disclaimer: Be aware, however, that this wonderful use of the web platform will not show your changes in Internet Explorer.
Now imagine if you had 20 components that needed a value updated. Design tokens are the answer! They give you consistency and scalability.
Utilities
Utilities are special CSS classes that handle specific, single-use situations.
A good example of a utility is the grid utility. The grid utility provides a set of classes to quickly create responsive, adaptive, mobile-first layout systems. It’s your go-to for composing layouts for your app.
We go deeper into grids and layouts in Unit 2 of this module.
Design Guidelines
Design guidelines are the principles and best practices that guide the user experience through common interaction patterns. Guidelines provide extensive instruction around user interface patterns, behaviors, markup, styling, voice and tone, and accessibility.
For example, this guideline describes when to use a toggle when creating a data entry interface. It provides clear instructions with visual dos and don’ts.
|
Example Guideline Use a toggle if the field you are building:
|
 |
Component Blueprints
Last but definitely not least are component blueprints. Blueprints are robust sets of user interface elements used to construct components and experiences.
Component blueprints are a set of semantic HTML, CSS, accessibility attributes, and guidelines. Blueprints are the key to SLDS being implementation-agnostic.
You can use blueprints to build your components in whatever web technology you want. For instance, you could leverage blueprints to build React components. Or you could use one of several out-of-the-box implementations of blueprints that exist today. One of those implementations is called Lightning Components, and they’re a big part of developing with SLDS.
Lightning Components
Lightning Components are the building blocks that make up the user interfaces for the modern Lightning Experience. When you are working on the Lightning Platform, Salesforce provides a library of the most commonly used components. Sometimes these are called Base Lightning Components. These components are your go-to resource when you’re building user interfaces. They should satisfy a majority of your needs. In some cases, you may want to create your own components. Bear in mind that the only things you should need to build are:
- Something that’s not been built as a Lightning Web Component by Salesforce
- Something custom that you can compose using blueprints
- Something totally new, using design tokens as the CSS values
We get into how to create your own components from SLDS blueprints in the next unit.
Lightning Web Components (LWC)
Lightning Web Components, commonly referred to as LWC, is the next major evolution of our base components and how we implement blueprints. The big difference here is that LWC is built around modern web standards and is natively supported by modern web browsers. So it has some advantages—particularly if you’re not used to developing on the Salesforce Platform.
When you use Base Components, you can choose to use either the Aura or LWC version. This article is a great place to learn about the differences. If you’re building your own component, you should always try to choose LWC as your technology. When you do, they inherit global HTML attributes and events, making them more functional and performant than their Aura counterparts.
LWC is... built on top of the concept of web components which give us the ability to build real, native components on the web using only web standards.
LWC is... fast, standards-based, open-source, easy to learn, and opens doors to new ways of thinking about how we compose components.
You can learn all about Lightning Web Components on the LWC website.
