How the Salesforce Lightning Design System Helped Me Onboard As a New Product Designer
I joined Salesforce UX last July as a full-time product designer, after a great summer internship in 2014. Fortunately for me, in the year I was off finishing grad school, Salesforce UX got a lot done. The team not only led the creation of Lightning Experience, Salesforce’s new, beautiful user experience, but they did it in a way that resulted in a set of design patterns and UI components known as the Lightning Design System. The Design System is awesome for many reasons, but I’d like to take a moment to celebrate it for the ways it benefits a new designer at Salesforce.
With the Lightning Design System, I can…
Solve Problems More Confidently
As an intern, I was intrigued by the kinds of problems inherent in designing enterprise software bought by over 150,000 customers and built and run by over 16,000 employees.
To design at Salesforce is to have to consider the whole ecosystem. Our users are extremely diverse, and they often spend their work days in several of our products. Our designs must be able to accommodate every customization thrown at them, while also maintaining consistency with patterns across all of our products. They must balance a wide range of user needs and habits with our product owners’ requirements and the resources of a large engineering organization.
In practice, this degree of complexity can be challenging for any designer. For a new designer at Salesforce, however, to try to manage all of this, while still learning what our products even do and who at the company knows what, is pretty daunting. In the last six months, I have, at times, felt frozen with uncertainty from feeling slow to catch on or from just being plain wrong.
Fortunately, the Design System has helped me move forward each day with some degree of confidence. Because it was created in a collaborative, user-centered way, the Design System has a lot of agreement baked in. I can rest assured that our users will understand the components and patterns I use and that my team won’t be distracted by whether I’m using the right blue-gray on hover. When I use the Design System, stakeholders are confident that my designs are appropriate for the product I’m working on, and engineers are happy that the code exists to actually ship them. All of the behaviors and styles are already there, and I only have to ask and answer important questions like, “Does this feature empower confident and efficient work for our users?”
With so much already decided for me by the Design System, I wondered at first if I was destined to merely consume it for the duration of my time at Salesforce. What else is there to do? How can I contribute?
I see now that one of the greatest things the Design System does is define what is. This in turn makes it easier to see what is not, yet. I know the agreed upon styles and behaviors, where they go, and where the relevant files are, but the Design System is young, and my team is new to adopt it. When I encounter a need not met by the Design System, I have the freedom to sketch, propose, or even prototype a solution. Alternatively, if there is a way to improve the process by which my team works with the Design System, I can jump in and make it a reality. I have, for example, already contributed to extending the Design System to our Admin experience and even used the system to code up a little toggle switch that didn’t previously exist. At the end of the day, the Design System provides structure for new designers to contribute to something larger.
Because of the Design System, my job and my development as a designer aren’t constant battles over key frames or hex values. Instead, they are about making work better for our users alongside a team of smart, hardworking people. This is fun. The Design System makes me a better, more confident Salesforce designer faster than I would be without it, yes, but it also makes work more fun.
For one, there are fewer specs. The Design System is a living document, and its HTML and CSS are online for everyone to access. Even better, it has also recently become our production CSS. Rather than spec every color and border on every screen for developers, I can now hand over an Invision or HTML prototype that illustrates a user flow and then simply refer to the names of components already in our codebase. If I need to, I can account for custom styles or components by including the Sass tokens that will create them. No matter what, I can express precisely what my designs should be, and I can do so with one interactive prototype.
Freed from some of the daily tedium that can come with being a designer, I can shift the bulk of my time and energy to looking at the bigger picture. I can think more widely about our users’ journey through our product and give attention to more than baseline functionality. It’s a requirement now, not a luxury, to make sure our users are comfortable and confident, and that the work they complete in our products is confirmed and rewarded. Needless to say, it’s rewarding to make work rewarding for our users.