Salesforce Lightning Design System (SLDS) PDF
Document Details
Uploaded by Carenem
Tags
Related
- Salesforce Certified Platform Developer I Exam Questions PDF
- Five9 Lightning Call Notes Workflow PDF
- Salesforce Sales-Cloud-Consultant Exam Questions and Answers PDF
- Declarative Design for Optimized Salesforce User Flow PDF
- Salesforce Lightning Design System (SLDS) PDF
- Salesforce Lightning Design System (SLDS) Past Paper PDF
Summary
This document provides an overview of Salesforce Lightning Design System (SLDS). It details the fundamental components of the design system, such as design tokens, utilities, guidelines, and blueprints, along with additional resources like the SLDS documentation and GitHub repository. It also explains concepts of Lightning Web Components (LWC), grid systems, and styling hooks.
Full Transcript
Salesforce Lightning Design System (SLDS) Given a scenario, determine out-of-the-box design and configuration consistent with the look and feel of Lightning Experience. ===================================================================================================================================...
Salesforce Lightning Design System (SLDS) Given a scenario, determine out-of-the-box design and configuration consistent with the look and feel of Lightning Experience. ======================================================================================================================================================================== **Salesforce Lightning Design System (SLDS) Fundamentals** The **Salesforce Lightning Design System (SLDS)** provides a set of guidelines and tools for building consistent, user-friendly, and accessible interfaces on the Salesforce platform. It is designed to ensure that applications built on Salesforce are visually cohesive, responsive, and functional. **1. Four Fundamental Elements of SLDS** These four elements form the core of SLDS and contribute to creating a unified design system for Salesforce applications. **1.1 Design Tokens** - **Definition:** Design tokens are named entities that store **visual design attributes** such as colors, spacing, typography, and other design-related values. - **Purpose:** They help maintain consistency across Salesforce applications by ensuring that design decisions (like color schemes, padding, etc.) are centralized and can be easily applied throughout the application. - **Example:** A design token could be a color palette (e.g., \--slds-color-brand-primary) that can be used across various components to ensure uniform branding. **1.2 Utilities** - **Definition:** Utilities are a collection of **CSS classes** designed to provide quick, reusable solutions for common layout and alignment issues. - **Purpose:** They allow designers and developers to adjust spacing, sizing, positioning, and other layout aspects without writing custom CSS, promoting faster development cycles. - **Example:** Utility classes like slds-p-around\_medium (for medium padding) or slds-text-align\_center (for center-aligning text) can be applied directly in HTML. **1.3 Guidelines** - **Definition:** Guidelines offer **comprehensive instructions** on implementing SLDS design patterns, components, and interactions. These ensure that all design elements are consistent and accessible. - **Purpose:** They provide best practices for building UI elements, defining user interaction behaviors, and adhering to Salesforce\'s branding and accessibility standards. - **Example:** SLDS guidelines will dictate how a button should behave when clicked, how to design modal dialogs, or how to structure forms for accessibility. **1.4 Blueprints** - **Definition:** Blueprints are **static, framework-independent HTML and CSS** components that serve as reusable building blocks for creating user interfaces. - **Purpose:** They provide a predefined structure that can be used as-is or adapted for specific needs, reducing the amount of custom coding required. - **Example:** A blueprint could include a pre-designed layout for a navigation bar, which can be directly implemented into a page. **2. Additional SLDS Resources** SLDS offers a range of additional resources to help developers and designers work more efficiently: - **SLDS Documentation:** This is the primary resource for all guidelines, components, utilities, and patterns. It provides detailed instructions on how to implement the SLDS design system in Salesforce applications. - **SLDS GitHub Repository:** Developers can access the **SLDS CSS framework** and other resources on GitHub to get the latest code and updates. - **SLDS Salesforce App:** For those building on Salesforce, the **SLDS Salesforce app** provides pre-built components and design patterns to speed up development. - **Salesforce Lightning Web Components (LWC):** LWC is a framework for creating reusable components that work seamlessly with SLDS. **3. Concepts of Lightning Web Components (LWC), Grid, and Styling Hooks** **3.1 Lightning Web Components (LWC)** - **Definition:** LWC is a **UI framework** built by Salesforce for developing **modern web components** that are lightweight, fast, and reusable. - **Integration with SLDS:** LWC integrates directly with SLDS, allowing developers to use SLDS components and styles within custom web components. - **Purpose:** LWC simplifies the development process by offering performance improvements and more flexibility compared to previous frameworks (such as Aura). **3.2 Grid** - **Definition:** The **grid system** in SLDS provides a flexible and responsive layout structure, allowing elements to be arranged in a grid format with rows and columns. - **Purpose:** It helps create responsive designs that adapt to different screen sizes, ensuring that interfaces look good on desktops, tablets, and mobile devices. - **Example:** A common SLDS grid layout might define a structure like: - \ - \Content A\ - \Content B\ - \ **3.3 Styling Hooks** - **Definition:** **Styling hooks** are CSS classes and variables in SLDS that allow developers to customize specific components and adjust styles without overriding the entire system. - **Purpose:** They give developers control over certain design elements (such as color, spacing, and typography) while maintaining consistency with the SLDS framework. - **Example:** Developers can use classes like slds-button\_brand for customizing buttons without altering the entire button design system. **4. Iconography in SLDS** Icons are an essential part of user interface design, providing **visual cues** that enhance usability and make navigation easier for users. SLDS includes a standardized set of **icons** that align with Salesforce\'s branding and design system. **4.1 Five Types of Salesforce Icons:** 1. **Standard Icons** - **Description:** These are the most commonly used icons in Salesforce, including icons for objects like leads, accounts, contacts, etc. - **Example:** The account icon (a building symbol) is a standard icon representing accounts in Salesforce. 2. **Action Icons** - **Description:** These icons represent actions that users can perform, such as editing, deleting, or creating records. - **Example:** The edit icon (a pencil) signifies an option to edit a record. 3. **Utility Icons** - **Description:** Utility icons represent common system functions or tools like searching, notifications, or settings. - **Example:** The search icon (a magnifying glass) is a utility icon used for searching. 4. **Custom Icons** - **Description:** These icons are typically used for custom applications or objects within Salesforce. - **Example:** Custom icons can be created to represent custom objects or functions within the system. 5. **Social Icons** - **Description:** These are icons used for social media integration or sharing, often used for social actions like liking, commenting, or sharing. - **Example:** A twitter icon (the Twitter bird) is used for social sharing in Salesforce. **5. Best Practices for SLDS Design** To create a **consistent and user-friendly interface**, it\'s important to follow best practices when using SLDS: 1. **Maintain Consistency:** - Use standard components and design patterns from SLDS to ensure consistency across the application. - Ensure uniformity in design choices (e.g., color, typography, spacing) by adhering to SLDS guidelines. 2. **Focus on Accessibility:** - Ensure all components are **accessible** by following WCAG guidelines. This includes providing alt text for images, ensuring adequate contrast, and supporting keyboard navigation. 3. **Use Responsive Design:** - Leverage the grid system and responsive utilities in SLDS to create layouts that work seamlessly on all screen sizes and devices. 4. **Use Reusable Components:** - Use SLDS components whenever possible to ensure that designs are both efficient and scalable. 5. **Optimize Performance:** - When using LWC, prioritize performance by minimizing custom code and ensuring components are lightweight and efficient. **Summary:** After studying this topic, you should be able to: - **Define** the four fundamental elements of Salesforce Lightning Design System (SLDS): design tokens, utilities, guidelines, and blueprints. - **Identify** additional SLDS resources, such as documentation and the GitHub repository. - **Explain** the concepts of Lightning Web Components (LWC), grid, and styling hooks and how they integrate with SLDS. - **Outline** the significance of iconography in SLDS and recognize the five types of Salesforce icons: standard, action, utility, custom, and social. - **Describe** the best practices of SLDS design to ensure consistency, accessibility, and scalability in Salesforce applications. **Fundamentals of SLDS (Salesforce Lightning Design System)** The **Salesforce Lightning Design System (SLDS)** is built on four fundamental elements that form the core of the design system. These elements help ensure consistency, efficiency, and accessibility in building user interfaces on the Salesforce platform. **1. Tokens** - **Definition:** **Design tokens** are named entities that store **visual design attributes**, such as colors, typography, spacing, and layout dimensions. - **Purpose:** Tokens ensure consistency across the application by standardizing design values. For example, you can define a token for primary color (\--slds-color-primary) that will be applied across the UI wherever the primary color is required. - **Common Examples of Design Tokens:** - **Spacing Tokens:** Store margin, padding, and spacing values (e.g., \--slds-spacing-medium). - **Color Tokens:** Represent specific color shades used in the UI (e.g., \--slds-color-text-default). - **Typography Tokens:** Store font sizes, line heights, and font families for consistent text styling (e.g., \--slds-font-size-large). **2. Utilities** - **Definition:** **Utilities** are **CSS classes** that provide specific styling and functionality, such as layout control, alignment, and visibility adjustments. - **Purpose:** They allow for fast and easy adjustments to the design without requiring the writing of custom CSS for common patterns and behavior. - **Examples of Utility Classes:** - **Alignment Utilities:** slds-text-align\_center to center-align text, slds-align-middle to align elements vertically. - **Spacing Utilities:** slds-m-around\_medium to apply medium margin around an element. - **Visibility Utilities:** slds-hide to hide an element, slds-show to display it. - **Sizing Utilities:** slds-size\_1-of-2 to make an element take up half the width of a container. **3. Guidelines** - **Definition:** **Guidelines** provide **best practices** and **recommendations** for designing and implementing consistent, functional user interfaces. - **Purpose:** SLDS guidelines help designers and developers make informed decisions on how to use components and patterns effectively, ensuring a seamless user experience. - **Key Areas of Guidelines:** - **Layout Principles:** Best practices for organizing and structuring page layouts. - **Interaction Patterns:** How elements like buttons, form fields, and menus should behave. - **Accessibility Guidelines:** How to design for accessibility, ensuring compliance with WCAG and other standards. - **Branding Guidelines:** Maintaining consistent use of Salesforce\'s colors, typography, and icons. **4. Blueprint** - **Definition:** **Blueprints** are **static, framework-independent HTML and CSS** templates that represent UI elements and provide a starting point for building user interfaces. - **Purpose:** They offer pre-designed and standardized solutions for common UI components, ensuring that interfaces built on Salesforce align with the overall design system. - **Example Blueprint Components:** - **Button Blueprint:** A standard button component styled with SLDS for consistency. - **Grid Blueprint:** A flexible grid system that can be used for creating responsive layouts. - **Form Blueprint:** A structured form with consistent spacing, labels, and input elements. - **Navigation Blueprint:** A basic navigation bar or menu component. **Summary:** The **fundamental elements of SLDS** are designed to ensure efficient, consistent, and accessible design and development: 1. **Tokens** store visual design attributes for consistency. 2. **Utilities** are CSS classes that provide styling and functionality for quick layout adjustments. 3. **Guidelines** document best practices and design patterns for creating user-friendly interfaces. 4. **Blueprints** offer static HTML and CSS templates for UI components, ensuring adherence to the design system. By leveraging these elements, Salesforce applications can maintain a high standard of design, functionality, and user experience across the platform. Fundamental Elements of SLDS **The Four Fundamentals of SLDS** The **Salesforce Lightning Design System (SLDS)** is structured around four core elements that ensure consistency, accessibility, and efficiency when creating user interfaces for Salesforce applications. These elements are **Design Tokens**, **Utilities**, **Guidelines**, and **Blueprints**. **1. Tokens** - **Definition:** Design tokens are **named entities** that store specific **visual design attributes**, such as colors, margins, spacing, font sizes, and styles. - **Purpose:** Tokens provide a standardized way to apply design values across the system, ensuring consistent visual styles and making it easy to adjust the look and feel of components globally. - **Examples:** - **Color Tokens:** \--slds-color-brand-primary (defines the primary color for the application). - **Spacing Tokens:** \--slds-spacing-large (for consistent margin and padding values). - **Typography Tokens:** \--slds-font-size-medium (defines font sizes for text). By using tokens, designers and developers avoid hardcoding values and ensure that updates to design attributes can be made centrally. **2. Utilities** - **Definition:** Utilities are **CSS classes** that provide **predefined styling and functionality** to quickly adjust and enhance the design and behavior of components. - **Purpose:** They allow for rapid development and adjustments without the need for custom CSS code. Developers and designers can use utilities to handle common design patterns and behaviors. - **Examples:** - **Spacing Utilities:** slds-m-around\_large (applies large margins around an element). - **Visibility Utilities:** slds-hide (hides an element from the view). - **Alignment Utilities:** slds-text-align\_center (centers text within its container). - **Sizing Utilities:** slds-size\_1-of-2 (makes an element take up half the available width). By using utilities, developers can efficiently create responsive and flexible layouts without worrying about repetitive custom CSS. **3. Guidelines** - **Definition:** Guidelines are **documented best practices** and **recommendations** for designing user interfaces. They cover everything from component behavior to layout structure and accessibility. - **Purpose:** Guidelines ensure that interfaces are built according to Salesforce\'s standards for consistency, usability, and accessibility. - **Examples:** - **Layout Guidelines:** Best practices for organizing UI elements to create intuitive and easy-to-navigate pages. - **Iconography Guidelines:** Rules for how icons should be used across the platform, ensuring they are easily recognizable and support functionality. - **Accessibility Guidelines:** Ensuring that design elements meet accessibility standards, such as color contrast, text size, and keyboard navigation support. By adhering to these guidelines, teams can ensure that the design system remains consistent and accessible, providing a seamless experience for all users. **4. Blueprints** - **Definition:** Blueprints are **static, framework-independent HTML and CSS** representations of UI elements that serve as foundational building blocks for creating components. - **Purpose:** They offer a base structure for common UI elements, ensuring that interfaces follow the SLDS design system and are easy to implement without starting from scratch. - **Examples:** - **Button Blueprint:** A pre-designed button with consistent padding, colors, and typography, ready to be used across the application. - **Form Blueprint:** A template for building forms with standardized input fields, labels, and error handling. - **Grid Blueprint:** A flexible layout structure for arranging elements in a responsive grid format. Blueprints help ensure that developers can quickly create components that are both functional and visually aligned with the SLDS standards. **Summary of the Four Fundamentals of SLDS** 1. **Tokens**: Named design attributes (e.g., colors, spacing, typography) that ensure visual consistency. 2. **Utilities**: Predefined CSS classes for common design adjustments (e.g., alignment, spacing, visibility). 3. **Guidelines**: Documented best practices and standards for UI design, behavior, and accessibility. 4. **Blueprints**: Static HTML and CSS representations of components, providing foundational structures for building interfaces. Together, these elements help streamline design and development processes, ensuring a consistent, cohesive, and accessible user experience across Salesforce applications. **Tokens in SLDS** **Design tokens** are the foundation of a design system, representing **named entities** that store key **visual design attributes**. These attributes include properties like **colors**, **spacing**, **typography**, and **sizing**, and serve as placeholders to manage design consistency across components and applications. **Key Aspects of Design Tokens** **1. Reusable Placeholders for Design Attributes** - **Definition:** Tokens are **reusable placeholders** for design properties like color, spacing, font size, etc., that can be referenced in the CSS. - **Purpose:** Instead of hard-coding individual values (such as \#FF5733 for a color or 16px for font size) directly into the stylesheets, designers use tokens that represent those values. - **Benefits:** - **Consistency:** Tokens ensure that the same visual design attributes (e.g., primary color or font size) are applied consistently across the entire application. - **Ease of Maintenance:** If the design value of a token (e.g., color or margin) needs to change, it can be done in one place (the token definition), and all elements that use that token will automatically reflect the change. **2. Enhancing Design Scalability** - **Definition:** Tokens help **scale design** by allowing quick updates to visual attributes across large applications. - **How it Works:** When a token\'s value is updated (e.g., changing the primary color token from blue to green), the change automatically propagates to all components and pages using that token. - **Benefits:** - **Centralized Updates:** Rather than modifying multiple instances of the same value throughout the application, developers and designers can change the token once, ensuring all relevant elements are updated simultaneously. - **Scalable Systems:** As applications grow, design tokens make it easy to manage large, complex UIs, ensuring that updates to design values are efficient and consistent. **Examples of Design Tokens:** - **Color Tokens:** - \--slds-color-primary: Primary brand color (e.g., \#0070d2). - \--slds-color-background-light: Background color for light backgrounds (e.g., \#f4f6f9). - **Spacing Tokens:** - \--slds-spacing-small: Small padding or margin (e.g., 8px). - \--slds-spacing-large: Large padding or margin (e.g., 24px). - **Typography Tokens:** - \--slds-font-size-medium: Default font size for text (e.g., 14px). - \--slds-line-height-normal: Line height for normal text (e.g., 1.5). - **Sizing Tokens:** - \--slds-size-small: Small size for elements (e.g., 50px width). - \--slds-size-large: Large size for elements (e.g., 150px width). **Summary:** - **Design Tokens** are reusable named values for key design attributes like color, typography, spacing, and sizing. - They **improve consistency**, ensure easy **maintenance**, and help **scale design** by allowing centralized updates. - By using tokens, teams can maintain a **uniform design system** while enhancing the **efficiency** and **flexibility** of development. **Utilities in SLDS** **Utilities** are **CSS classes** that provide specific styling or functional enhancements to elements, typically for **single-use situations**. They are designed to enable **quick and consistent adjustments** to UI components without the need for custom CSS code. **Key Aspects of Utilities** **1. Design Guidelines** - **Definition:** Utility classes are predefined **CSS classes** that implement common design patterns or behavior. These classes can be applied directly to HTML elements to modify their appearance or functionality. - **Purpose:** Utilities allow developers to avoid writing custom CSS for common tasks, speeding up development and ensuring adherence to the design system's standards. - **Examples:** - **Grid Utility:** A set of CSS classes that helps developers build responsive layouts. For example, the grid utility allows you to define columns and manage layout responsiveness across different screen sizes. - **Spacing Utility:** Classes that manage margin and padding, such as slds-m-around\_large for adding margin around an element. **2. Consistent Styling Across Elements** - **Definition:** Utilities help maintain **consistent styling** and **behavior** across different UI elements throughout the application. - **Purpose:** By applying the same utility classes to multiple elements, developers can ensure **visual consistency** without needing to replicate styles across various components. - **Benefits:** - **Efficiency:** Utilities allow developers to quickly adjust the layout, alignment, or visibility of elements without writing additional CSS code. - **Maintainability:** By using standardized utility classes, the application becomes easier to maintain since the styling logic is centralized and reusable. - **Consistency:** Utilities ensure that common design elements behave the same way across the application, whether it's for spacing, alignment, or visibility. **Examples of Utility Classes in SLDS** 1. **Spacing Utilities:** - slds-m-around\_medium: Adds medium margin around an element. - slds-p-horizontal\_small: Adds small horizontal padding inside an element. 2. **Alignment Utilities:** - slds-text-align\_center: Centers text horizontally within an element. - slds-align-middle: Vertically aligns elements to the center within a container. 3. **Visibility Utilities:** - slds-hide: Hides an element from view. - slds-show: Displays an element that may have been hidden previously. 4. **Sizing Utilities:** - slds-size\_1-of-2: Makes an element take up half of the available width in a container. - slds-size\_1-of-3: Makes an element occupy one-third of the container's width. 5. **Flexbox Utilities:** - slds-flex: Applies a flexbox layout to an element. - slds-flex\_column: Aligns children elements in a vertical column layout. 6. **Background and Color Utilities:** - slds-text-color\_error: Changes the text color to indicate an error (e.g., red). - slds-bg-light: Applies a light background color. **Summary:** - **Utilities** are predefined CSS classes in SLDS designed for **quick, one-time adjustments** to elements, such as spacing, alignment, visibility, and sizing. - They help achieve **consistent styling** across UI elements and **speed up development** by removing the need for custom CSS. - By using utilities, developers can easily implement **common design patterns** and ensure that the application maintains **visual and functional consistency**. **Design Guidelines in SLDS** **Design guidelines** are the comprehensive set of principles, patterns, and best practices that provide a framework for designers and developers to create consistent, intuitive, and accessible user interfaces within the Salesforce ecosystem. **Key Aspects of Design Guidelines** **1. Framework for Designers and Developers** - **Purpose:** Design guidelines help guide the design of user interfaces by answering key questions related to **data presentation**, **data input**, **search functionality**, and how the UI should **communicate loading states**. - **Benefits:** They provide designers and developers with clear instructions and consistent standards, ensuring that Salesforce applications are visually cohesive and user-friendly. **2. Blueprint Design** - **Definition:** **Blueprints** in SLDS are static HTML and CSS code representations of UI elements. They provide the foundational structure for creating components according to the implementation guidelines. **Key Characteristics of Blueprints:** - **Static:** Built using HTML5 and CSS, these blueprints don't include dynamic or interactive behavior, so they need to be integrated with JavaScript frameworks to be functional. - **Framework-independent:** Blueprint code is designed to work with any JavaScript framework, providing developers with flexibility in their choices of frameworks and tools. - **Accessibility:** Blueprints are designed to be accessible, ensuring that components are usable by everyone, including people with disabilities. **Other SLDS Resources** In addition to the core design system elements, SLDS provides a wealth of resources to further assist with the design and development of Salesforce applications: **1. Tools** - SLDS provides various **APIs**, **plug-ins**, and **design kits** to streamline the development process, making it easier to build applications quickly and consistently. **2. Voice and Tone Guidelines** - SLDS includes **voice and tone guidelines** that help maintain a clear and consistent communication style throughout all Salesforce content. These guidelines ensure that on-screen instructions, error messages, and official communications align with Salesforce's brand and user experience principles. **3. Accessibility Guidelines** - SLDS follows **WCAG 2.0 AA** standards to ensure that all Salesforce applications are **perceivable**, **operable**, **understandable**, and **robust** for users with disabilities. **Lightning Web Components (LWC)** **Lightning Web Components (LWC)** is Salesforce\'s programming model for building interactive and efficient web applications within its ecosystem. - **Interactive User Interfaces:** LWC uses standard web technologies like **HTML**, **JavaScript**, and **CSS** to create rich, interactive user interfaces. - **Benefits:** - Adheres to web standards. - Open-source and easy to learn. - Speeds up development by providing an efficient way to create responsive web applications. **Grid System in SLDS** The **Grid** system is a set of CSS classes used to create **responsive and accessible** layouts within Salesforce applications. - **Responsive Layouts:** The grid system helps developers create flexible layouts that adapt seamlessly to different screen sizes, ensuring a consistent user experience across desktops, tablets, and mobile devices. - **Consistent Look and Feel:** It simplifies the process of building responsive interfaces while maintaining visual consistency throughout the application. **Styling Hooks** **Styling hooks** are **CSS custom properties** that allow developers to apply consistent styles to SLDS components and customize their appearance. - **Standardized Component Styles:** Styling hooks help ensure that all components adhere to SLDS design guidelines, even when developers customize them. - **Range of Attributes:** Styling hooks can be applied to a variety of UI elements, including typography, colors, spacing, and alignment, making it easier to modify components without writing custom CSS. **Iconography in SLDS** **Iconography** refers to the use of visual symbols (icons) to communicate information, actions, and concepts within the Salesforce interface. **Five Types of Salesforce Icons:** 1. **Action Icons:** - Used to indicate actions next to UI elements like headers or cards. These are primarily for touch devices. 2. **Object Icons:** - Represent standard (e.g., Accounts, Leads) or custom objects within Salesforce. 3. **Utility Icons:** - Simple, single-color symbols that are used for labeling or indicating actions across Salesforce applications. 4. **Product Icons:** - Represent different Salesforce products with logos, using official color schemes and full-color designs. 5. **Document Type Icons:** - Icons representing document file formats (e.g., PDF, Word) with a white symbol on a folded paper background. **Modals and Non-Modals in UI** **Modal Dialogs:** - **Definition:** A modal dialog requires the user's immediate attention and prevents interaction with the rest of the interface until a response is provided (e.g., a confirmation message or alert). - **Example:** **Welcome Mat** is an example of a modal dialog in Salesforce. **Non-Modal Dialogs:** - **Definition:** A non-modal dialog allows users to interact with other parts of the application while the dialog is open. It typically provides additional information without requiring immediate action. - **Examples:** **Popovers**, **Docked Composers**, **Notification Cards**, and **Panels** are all examples of non-modal dialogs that provide supplemental information or options to users. **Summary** SLDS provides a comprehensive set of **design guidelines**, **blueprints**, and **resources** that help ensure Salesforce applications are **consistent**, **efficient**, and **accessible**. From **interactive components** (LWC) to **responsive grids** and **styling hooks**, SLDS streamlines the development process, enhances user experience, and ensures that applications are built in line with **Salesforce's branding** and **accessibility standards**. **Best Practices for SLDS Customization and Styling** When working with the **Salesforce Lightning Design System (SLDS)**, following best practices ensures that the application maintains **visual consistency**, **performance**, and **accessibility** while also providing flexibility for customization. **1. Customize Thoughtfully** **Avoid Overriding Styles** - **Principle:** Rather than **overriding** SLDS styles directly with custom CSS, use **SLDS customization options** to modify elements where necessary. - **Reasoning:** Overriding default styles can create inconsistencies and lead to maintenance challenges over time. It also prevents your application from benefiting fully from the **SLDS updates** and changes that may come with future releases. **Best Practice:** - **Customize** using SLDS tokens, utilities, and classes. - Avoid creating **ad-hoc solutions** that bypass the system\'s structure. **2. Use Design Tokens Wisely** **Ensure Tokens Align with Design Intentions** - **Principle:** When using design tokens, ensure they are applied to the correct properties and elements. - **Reasoning:** **Design tokens** serve as reusable placeholders for visual properties (like colors, typography, spacing). It is essential to align the token\'s value with the design intention to ensure consistency across the application. **Best Practice:** - Carefully select design tokens that match the specific **scope** and **property** (e.g., spacing, color, typography). - Using the wrong tokens can lead to **inconsistent styles** and unintended design variations. **3. Prioritize Smart Styling Habits** **Effective CSS Practices** - Practicing **clean and efficient CSS** is key to maintaining a manageable and scalable codebase. **Good CSS Practices Include:** - **Avoid Type Selectors with Classes:** - Don\'t combine type selectors (e.g., div) with classes (e.g.,.my-class). This can cause **future markup complications** and make styles harder to maintain. - **Keep Selectors Short:** - Shorter selectors are easier to read, maintain, and less prone to **specificity issues**. Overly nested selectors can make it harder to troubleshoot and scale. - **Minimize Universal Selector Usage:** - The universal selector (\*) applies to all elements and can cause **unpredictable conflicts**. Use it sparingly and in well-controlled scenarios. - **Use !important Sparingly:** - The use of the !important declaration can signal deeper **CSS issues**. Overusing it can lead to cascading problems and makes it more challenging to manage styles in the long term. **4. Embrace the SLDS Principles** By aligning with these best practices, you ensure that you: - **Preserve consistency** in design across applications. - **Maintain scalability** and flexibility in your design system. - **Minimize future technical debt** and improve the overall **user experience**. These best practices allow for a **seamless** customization of SLDS while respecting the system's design philosophy. By customizing thoughtfully, using tokens properly, and maintaining good CSS hygiene, your Salesforce applications will be **cohesive**, **efficient**, and **easier to maintain**.