Beyond Components: A Design System to Support Multiple Frameworks
At Salesforce, we like to say that Lightning Design System faces unique challenges. That’s true, but it’s also something we’re proud of. Most of those challenges stem from success — and in order to continue that success, we have to address them in innovative ways.
Case in point: In the three-year history of the Salesforce Lightning Design System (SLDS), Salesforce has acquired 22 companies (yes, 22) — each with technologies that must be integrated into the Salesforce ecosystem. Our platform designers and engineers come from a wide range of backgrounds, in almost every market segment and industry. They work in frameworks that include React, Angular, and Vue, as well as our internal frameworks, Visualforce and Lightning. Both they and the customers they serve need a design system that supports a ridiculously wide range of solutions.
Flexible, Framework-Agnostic Component Blueprints from the Start
So how did we build a design system that meets all of these needs? Most modern design systems are made up of reusable programmatic components, assembled in one or more functional markup languages and built on specific front-end application frameworks. But what happens when a system must support multiple application frameworks?
When we began designing the system in 2015, we explored many options, seeking a solution that could support a range of existing and possible frameworks. We chose to abstract the markup to make it framework agnostic, based on accessible HTML and CSS scaffolding we call component blueprints.
Lightning Design System component blueprints: Framework-agnostic, accessible HTML and CSS elements used to create components
The designers and engineers at Salesforce and the Salesforce community use our blueprints to create unique functional components built on a range of application frameworks. Over the years, this powerful, flexible, and remarkably adaptable solution has grown to support a wide range of solutions across the Salesforce ecosystem.
Comprehensive Pattern Guidelines
Today, Lightning Design System has become a key resource for millions of Salesforce customers and partners. To help everyone in the community better understand (and use!) the system, we’re focused on enhancing and expanding our pattern guidelines to complement the existing developer-focused documentation. Designers building Salesforce applications can use these patterns to create consistent, high-quality user experiences in line with the larger Salesforce brand.
Lightning Design System patterns: Principle-driven guidelines to help designers create consistent user experiences
About Those Challenges…
At Salesforce, clarity is our primary core design principle. But one of the side effects of rapid growth is that we haven’t always lived up to that goal when it comes to consistent naming within and across systems. The blueprints described here were originally called “components” — a term that can also refer to functional markup within a JS framework. To clarify the difference, we’ve renamed the components section of our system Component Blueprints.
The Design System as a Service
All of these changes reinforce how important it is that we keep developing tools, best practices, and systems to serve an expanding ecosystem of people and solutions. Salesforce is a service, and to support its ecosystem, our design system must work as a service too.
Follow us at @SalesforceUX.
Want to work with us? Contact uxcareers@salesforce.com
Check out the Salesforce Lightning Design System
Special thanks to Brandon Ferrua, Adam Doti, Lisa Gluskin Stonestreet, Kyle Haskins, Allison Ivmark, Cordelia McGee-Tubb, Stef Rewis, and Simon Taggart
