Evolving a Design System at Scale
How Salesforce UX uses cross-product themes to update our design system
Process as Practice
Salesforce is a large company with more than 200 product designers, nine major product groups, and dozens of product acquisitions. Our size makes it unfortunately easy for user experience inconsistency to creep into our products. Designers from different product groups can be working on similar functionalities, yet unaware of each others’ work because we are a globally distributed team operating at scale.
The Salesforce Lightning Design System (SLDS) is our solution to this problem. It’s a living design system, meaning it is constantly evolving based on business needs. Product designers contribute to and consume the design system by following a blended, federated, and centralized team model:
The Centralized Design Systems team acts as a librarian, distributor, and facilitator ...The Federated Design Systems contributors … keep the Design System accurate, current, and actually useful.
— Jina Anne
So how does this work?
Introducing Themes
Over the past year, as SLDS has evolved to become a design system as a service, we began codifying the process of creating design guidelines for similar product families and functionalities.
When we identify cross-product UX misalignment, we flag it as a UX theme around which we do a design spike. Themes are very important for us because they support Salesforce’s top company value, trust—meaning our customers’ trust in our products and services.
A theme is a scoped deep dive into exploring how an experience should align across many products. It can have a broad scope, such as a type of tool, or a specific focus on one functionality, such as search.
Example Theme: Builder
Recently, I participated in the development of new design guidelines for builders, a type of tool that allows Salesforce users to build and visualize applications and business processes using little to no code.
The builder theme encompassed six distinct tools from multiple products, including two from acquired companies: Flow Builder, Lighting App Builder, Bot Builder, IoT, Journey Builder, and Engagement Studio.
Let’s dig into how the Salesforce design team uses the themes process to drive consistency, referencing the builder theme as a concrete example.
The Theme Team
Design is always a team sport, involving many players who together take a theme from an idea to a set of refined design guidelines.
The Theme Design Council
First off, the design council. Designers from theme-related products form a working group to architect the design guidelines. Together, these designers share the responsibility of defining how products in the theme should be aligned.
Typically, a council has six to twelve contributors. We try to balance representing all related products with having an efficiently sized group.
The council meets weekly, identifying topics within the theme that require alignment. Each topic has a design owner, who does the legwork of defining the design pattern, presenting a point of view back to the council, and incorporating team feedback.
In the builder theme, for example, the council identified messaging as one topic worthy of further definition. Salesforce already has general guidelines for messaging, but the council found use cases among builders that were not covered under the general guidelines. As a consequence, each product had been using messaging components in a different way.
The council worked together to align how builders should message success, failure, errors, and other information. The result of that effort is a section within the builder guideline on how to use the existing popover message component to meet builder use cases, along with new variants on that component.
The Theme Lead
The theme lead supports the council as facilitator and primary point of contact. With so many designers on the council — and such a large UX organization overall — it’s most efficient to select one person to run meetings and communications within the group. The theme lead also serves as the ongoing steward of a guideline—keeping an eye out for future updates to the pattern and acting as a subject expert.
As the theme lead of the builder design guideline, I envisioned my role as the editor of an anthology, helping the council deliver their aligned specs as a cohesive body of work to SLDS. I also collaborated with the process lead to set and meet project milestones and communicate progress to leadership.
The Process Lead
The process lead is another crucial player in the themes process. At Salesforce, this designer is one person, SLDS lead designer Alan Weibel.
As process lead, Alan helps identify UX themes that need alignment and need to be documented in our design system. He works with UX leadership to continually prioritize the pipeline of themes. And he works across multiple theme design councils to support them all.
For the builder theme, Alan helped us design the design process: suggesting project milestones, communications plans, and council members. He evaluated the emerging design guideline through a systems-based, as opposed to product-based, lens. His involvement helped ensure that the resulting solutions scale beyond any one product’s specific needs.
At a higher level, Alan educates the UX organization on how the themes process works, and communicates progress and updates to executive design leadership and the SLDS team.
Publishing to Salesforce Lightning Design System
Once a theme guideline is finalized, it is added to the SLDS website. Now, all other designers at Salesforce — and partners building on our platform — can reference it as an official pattern. The published theme represents one significant step closer to experience consistency — but not the final step.
Getting this consistency into product is its own journey for each product team. Once the UX team is aligned internally, each product team must address this “trust debt” (aka design debt) and make the necessary changes.
Once the builder theme was complete, each member of the design council went back to their product team and presented a vision of what their builder would look like using the newly aligned patterns and components. These designers also shared that visions with their product managers and engineers, working to obtain a commitment from the product teams to add these enhancements to backlogs and assign a future release goal.
An Evolving Approach for an Evolving Design System
Looking back on my experience as a theme lead, I value it as an opportunity to flex a different kind of leadership muscle. I was accountable for the group’s output, but not entirely responsible for the design definition. I also enjoyed the challenges and rewards of shepherding a group of talented senior designers toward a shared goal.
Themes are a new approach for us, and the cyclical relationship between product designers and the Salesforce Lightning Design System continues to adapt — what I have described here is not an immutable process. We are always looking for ways to improve, innovate, and do better. I expect that a year from now, we will have new lessons and reflections to share.
Thank you Alan Weibel, Raymon Sutedjo-The, Lisa Gluskin Stonestreet, Caroline Alix, and Jason Kriese for your feedback, edits, and guidance.
Follow us at @SalesforceUX.
Want to work with us? Contact uxcareers@salesforce.com
Check out the Salesforce Lightning Design System
