Brandon Ferrua is a UX architect for the Design System team here at Salesforce. In this episode, we discuss the history of the Salesforce Lightning Design System. He teaches us what a design system really means. Brandon also reveals a cool new feature in the form of styling hooks.
If you’ve ever wanted a more detailed understanding of design systems, Brandon has been here since the bootstrap days and has a lot to teach us. Tune in to hear a great conversation with lots of useful information.
Show Highlights:
- The history of SLDS.
- What makes a design system a design system.
- How Salesforce started getting organized with accessibility-friendly components.
- What a design token is and how it works.
- The core products and users they were specifically designing for Lightning Experience
- What styling hooks are and how they help the adoption problem.
- What kind of freedom the new styling hook feature gives people.
- The advantages the Trailhead design team will experience.
Links:
- Brandon on Twitter: @bferrua
- Salesforce UX Github: https://github.com/salesforce-ux
- SLDS Styling Hooks: https://www.lightningdesignsystem.com/platforms/lightning/styling-hooks/
- Salesforce UX Blog: https://medium.com/salesforce-ux
Episode Transcript
Brandon Ferrua:
We had this challenge of migrating a massive platform customer base over to this new Lightning Experience that was going to increase their usability, increase their consistency, all this stuff, make them more productive.
Josh Birk:
That is Brandon Ferrua, a UX architect for the design system here at Salesforce. I’m Josh Birk, a developer evangelist with Salesforce, and here on the Salesforce Developer Podcast you’ll hear stories and insights from developers for developers. Now, today we’re going to sit down with Brandon and talk about the history of the Lightning Design System, what a design system really means, and a cool new feature in the form of styling hooks.
Josh Birk:
But before we get going, I personally want to thank everybody who participated in our podcast survey. We have finished that. The results are in. I was delighted to read a lot of your feedback. I’ve taken some notes, but also just really glad that a lot of people seem to be really enjoying the podcast. And so I want to thank everybody who participated, and I also just want to thank everybody for listening. This is our 50th episode. When we first started putting this show together years ago, we’d been trying to think about what a podcast would look like. At one point, I honestly wasn’t even sure if we would have 50 episodes. So I just want to take a pause and just say that it’s been great to get here, and my goal is definitely to give you at least 50 more episodes in the future.
Josh Birk:
Now, getting back to the show, we start with the history of SLDS, which actually began a little bit before the Lightning Experience.
Brandon Ferrua:
It started a little bit before that. It was actually around the time when we rolled out the first S1 mobile experience, so… I’m trying to remember what year that was. It was before I got here, but that was where some of the team, [inaudible 00:01:55] and Jina Anne, who were running a team that was kind of conceptualizing what a source of truth could be for design, right? That’s where the first introduction of what we refer to now as design tokens was conceptualized. That was a way to just provide a source of truth that both designers can reference and engineers could use that could say, “Hey, Salesforce brand blue is this color, and if you use this token, you’ll maintain that consistency across all of the products and platform.” So that’s where that [inaudible 00:02:31]. That kind of, “Hey, we have a problem that we need to solve,” was exposed at that time. And then as the Lightning Experience was being considered and conceptualized, we’ve kind of used that as opportunity to broaden the scope of the design system and actually build and distribute code that was otherwise… we weren’t able to do with the mobile experience, but with the desktop experience we were able to do.
Josh Birk:
And it’s interesting, it actually took a conversation… I was working with Jina at a world tour, and she was going to do a presentation. And I think now it’s been so long since those Wild West days of the Salesforce1. I remember there was the Bootstrap project. If you wanted to make your Visualforce page look like Salesforce1, you would load this theme for Bootstrap basically. And then going into what a design system actually is and the maturity of that experience in the organization… So I guess let’s knock out a couple of terms for people. First of all, what makes a design system a design system?
Brandon Ferrua:
So that’s a great question, because I think over the years we’ve been trying to discover, what does that term mean? And it meant different things for different people, but I think to us what it means is, it’s a mechanism, like a centralized, foundational way that we can communicate out, basically, design decisions, and document and store that source of truth that I’m referring to not only code-wise but also design documentation. So it’s a platform in which we want to capture, what are consistent user experience patterns that we see within our product? Store it, centralize it, so then all teams can kind of reap the benefits of the work that was done around that particular pattern. The next is the accessibility aspect of it. It was a way for us to kind of document what our standards are in terms of accessibility and how we expect our product to perform from an accessibility standpoint. And then the last piece is kind of the engineering side, and the team that I work on is just, we wanted a way to take those design decisions and accessibility decisions and actually create, distribute, and code out of that, right?
Brandon Ferrua:
And so that’s where we started creating what we refer to is component blueprints, because at the time we wanted to have as large of a impact and scope that we could, so we wanted to build an agnostic product that could be used, say, within the AURA platform, or it could be used off-platform, say, in like React or Angular, whatever the new, cool framework was at the time, right?
Josh Birk:
Right.
Brandon Ferrua:
And it was a way just to enable customers to kind of build their products to look and feel like the Lightning Experience.
Josh Birk:
[crosstalk 00:05:26].
Brandon Ferrua:
But then also have our design decisions kind of baked into that code, right?
Josh Birk:
Right.
Brandon Ferrua:
And so it was just a way for us to kind of document and communicate design decisions through code.
Josh Birk:
Yeah. Well, and a couple of follow-ups there, but one is, I just want to show the appreciation in the structure of the naming convention, as opposed to back to those Bootstrap days when it was like… I think it was named on the off of things that maybe was like had been abused back in Classic or something like that. So that’s so much more modern.
Josh Birk:
Also, so you mentioned semantic HTML and accessibility, and listeners from the old days of the podcast might remember [inaudible 00:06:09] talking about how semantic HTML is kind of like the best foot forward right now for building accessibility-friendly components. Was Lightning Experience really kind of the first time that we really started getting organized around that?
Brandon Ferrua:
Yeah, I would say so, at least from my knowledge and understanding of… I mean, it’s always been a goal, and we’ve had a dedicated team that was primarily used as a consultants for our internal developers kind of building our products. I think it was a way where, we have some product requirements that we have to meet a certain kind of baseline of how accessible our product is, and that is, we want to make sure that we provide just an inclusive experience for our customers, regardless of whatever type of… a keyboard user, visually impaired. There’s a lot that needs to be taken in consideration, and we take it very seriously. And I think it was a way for us to kind of take a holistic look at how inaccessible maybe the previous product, i.e. Classic, might have been, and use it to kind of reinvent ourselves in being kind of a thought leader in the accessibility space.
Josh Birk:
Gotcha. And then one more definition, which I think is going to come up later, what’s a design token and how do they work?
Brandon Ferrua:
A design token… So it’s a cool name, but what it really is is a platform-agnostic design property stored in code. And what I mean by that is, if it might register more with our audience here today, it’s basically just a name and a value pairing. So we have this tool that we built in-house called Theo, and what that does is, we basically take design properties after working with our design team… Say Salesforce blue. We’ll just use that as a great example. We want to create a semantic name for what the semantic value is, so in this case… I think we have a naming pattern of how design tokens are kind of created, so in this case it would just be like color brand. It’s a really rudimentary example of it. And that stores our brand blue. And what that does is, we give it to the Theo tool, and it generates platform-specific files so we can manage one single source of truth, but then the AURA platform can understand that value, iOS can understand that value, Android can understand value, et cetera, et cetera. We can add as many platforms that we want, but it’s a way for us to kind of make it so if we ever change that color-
Josh Birk:
So like a dictionary value for the various decisions you’ve made.
Brandon Ferrua:
Yeah. Yeah, because we have a very complex system that we’re we’re building for, and our customers are building complex solutions to their problems, and so we had to have a way to quickly roll out changes if we needed to do so. In one way, a great example, I think, is if we wanted to darken our brand blue a little bit in the product just to make it a little bit more accessible, and we were able to make just one change, and it kind of propagated throughout the entire system. So that’s the cool thing about design tokens. But it goes beyond color too. Like we store like text, text values, text sizing, spacing values, all that type of stuff, so-
Josh Birk:
Right, but I like that example for a podcast, because when you say Salesforce blue, people can visualize that pretty easily.
Brandon Ferrua:
Yeah, yeah. Yeah, we have some crazy ones in there, but Salesforce blue I think everyone could probably understand.
Josh Birk:
Right.
Josh Birk:
Okay, so when this is starting to roll out, and Lightning Experience was starting to roll out, what were some of the core products and, I guess, the users that you were specifically designing for?
Brandon Ferrua:
At the time, it was for our flagship CRM products, so primarily it was the sales cloud, Service Cloud, product that we were focused on, because at the time they were the first adopters of the Lightning Experience.
Josh Birk:
Of Lightning Experience.
Brandon Ferrua:
Yeah. But over time, I think, that has grown.
Josh Birk:
Yeah. That was kind of my follow-up question, is like, how have you seen multiple personas in use cases as adoption has grown over the years?
Brandon Ferrua:
Yeah. I have personally seen the complexity of the system grow due to the fact that more people wanted to get on and migrate to the Lightning Experience because of all the benefits that it provided, especially nowadays that we have Lightning Web Components. People are excited about that and want to use it. They’re building awesome products and applications off of that framework, right? So especially over the years, as the company has grown with certain, say…
Josh Birk:
Right, it’s like the elephant in the room when it comes to this stuff. I think my next quip was going to be something like, “We’re Salesforce, so of course, nothing ever changes, and we don’t buy companies or anything.”
Brandon Ferrua:
Yeah, no, not at all. Not at all. So yeah, we can speak honestly about that. We tend to have a new company every six months or so. I don’t know what the actual statistics are around that, but point being is, we have to adapt to the scale of the company, because this company is not going to… It wasn’t going to stay where it was. And so we’ve seen it grow, and we kind of ran into some issues with the existing kind of architecture that enabled both internal and external and customers to customize their experiences as the requirements of their business grew.
Josh Birk:
Right, because I could imagine that complexity is going in a couple of dimensions. One, you’re getting new personas and new users who have new use cases, possibly needs for components that were never dreamed of back in the days of the sales cloud. But then you’ve also got like MuleSoft and Heroku. Sometimes we buy a company and our users probably don’t even know that that new feature that just rolled out was actually a purchase that we made two years ago or something like that. But then we’ve got Heroku, we’ve got MuleSoft, we’ve got companies that have these really distinct brands to them, so I would imagine that’s a whole other dimension where they have their own design concepts that aren’t necessarily lining up to that Salesforce blue.
Brandon Ferrua:
Yeah, exactly. I think you’re exactly right. Those kind of feature requirements and feature requests of the personas for that individual to kind of be most productive in their day-to-day job, the services that Salesforce wants to provide for our customers, it’s going to be unique to that product, right? But then on the flip side of all of that, that product, though it might be built on the Salesforce platform and take advantage of the services that we are providing, there are scenarios where they want to maintain some of their brand integrity, right?
Josh Birk:
Right, right.
Brandon Ferrua:
It’s important to them, and it’s important for us to enable them to be able to kind of communicate the intention of their identity as well, regardless of the fact that they may be building on the Salesforce platform.
Josh Birk:
Right. Okay, so then we’ll get to the other star of the show. What are styling hooks, and how do they help this adoption problem?
Brandon Ferrua:
So styling hooks was, I think, given some of the problem areas that I’ve been talking about a little bit, was our solution to enabling customers to keep that brand integrity and be able to kind of customize their experiences that are tailored to the personas of the people that are using their product, right?
Josh Birk:
Right.
Brandon Ferrua:
So this was conceptualized… Oh man, when was it? Maybe… We started initially talking about it probably a year and a half, two years ago. And the reason where that kind of came about was the introduction of the Lightning Web Components. And Lightning Web Components, we believe and feel that that is the framework of the future for [crosstalk 00:14:52] our customers will build on Salesforce. Gives a lot of benefits, and with that, it enables us to take advantage of the standard specifications set by the standards body of like the W3C, for example.
Brandon Ferrua:
And one of the critical functionalities that provides us is this concept called CSS custom properties. And CSS custom properties will enable us to do exactly what those design tokens kind of did for us, but instead of us having to rely on a tool like Theo to kind of generate these platform-specific tokens, if a product is being built on the web platform, say, just any web browser, even down to your phone where the behind the scenes that’s still half your applications that you might be using, even like your Safari on your iPhone or whatever, that’s still a web browser that takes advantage of that specification. And so we’re storing those name and value pairs now in CSS custom properties. But in addition to that, it enables us to allow for just greater customization for our customers’ components that they build, and then also if they’re using such things as like the Lightning Base Components that I believe we’ll be open-sourcing here shortly, but-
Josh Birk:
Yes, I think last I talked with… I think it was Kevin Hill. Many of them are open source, and then the path forward is new components will be open-sourced first as much as possible and then brought back to the platform as opposed to the other way around.
Brandon Ferrua:
Yeah. And I might get a little technical here.
Josh Birk:
Please do. Please do.
Brandon Ferrua:
So one of the benefits that styling hooks enable us to do through the specification of web components is this concept of encapsulation and kind of native shadow boundaries. So if you use the LWC framework as-is off platform, you will have the native shadow boundaries turned on, right? And there’s a slight problem with when native shadows boundaries get turned on, is it blocks cascading of CSS styles from getting into your component. Which is great, right? That’s what you want. You want to have some level of protection so some other component on your page doesn’t change, something within your component thus like breaking in or changing the integrity of it.
Brandon Ferrua:
But one thing that CSS custom properties, which the styling hooks are built upon, is, it can penetrate through shadow boundaries, which is fantastic, because then for us, we can still maintain that central source of truth that says like, “The color of my buttons across my whole system are Salesforce blue,” for example, but regardless of if you’re using styling hooks outside of LWC or within LWC, you’ll still get the same benefits, that by changing that one value, now you can do it through like JavaScript, or you can do it through a tool like Theo, for example, but basically you can just target one of the styling hooks that are exposed within your component, and then you can start modifying the properties of that look and feel of that component in a supported way.
Brandon Ferrua:
And I think that that’s a critical part, is the fact that we’re finally offering a supported solution for you to change and customize the look and feel of your component and have it completely separate from… No more hard-coding values into your component. All your customization is going to be taken off platform, on platform. It doesn’t matter. So I think it’s going to provide real value for people feeling confident that they can make the customizations that they need to their component to meet their brand.
Josh Birk:
Yeah. When we had talked about this earlier, you described this as like boxes with freedom. So kind of define that a little bit for me. Like when I’m thinking about that box, what’s the size and the shape of the box? Is that the component, the page, the application, my whole system? And then what kind of freedom are you giving me?
Brandon Ferrua:
Yeah, so right now, within this latest release, I believe it’s winter of ’21, we’re enabling customers to target specific components. That’s the limitation of it right now. We do have plans to expose what we’re going to be referring to as global styling hooks in the future, and I know I can talk about that, because it’s definitely on our roadmap [crosstalk 00:19:42]. No need for any forward-thinking statements.
Josh Birk:
Forward-looking statements, safe harbor, et cetera, et cetera.
Brandon Ferrua:
Safe harbor. But I think what that will enable our customers to do is, say, make application-wide changes, versus right now where we’re just enabling the kind of contextual scope down to the component. So we’ll provide styling hooks, say, for lightning button, which you can kind of change holistically, or you can target a specific button on your page and kind of customize it that way. Or we have a… I think we released… Let me see… About 12… Yeah, about 12 components in this release. So I mean, I think the expectation is that list will grow over time, but this is kind of our, “Hey, we’re going to roll out this feature.” We’re rolling it out under a beta tag, so it might not have all the properties exposed that some of our customers might require, but we’re looking for feedback from our customers about, what are the things that they’re trying to do? And we want to take that in consideration. I think over time we’ll move more of our styling hooks into a GA state, and they will be widely supported across our ecosystem.
Josh Birk:
Okay. So, I mean, baby steps.
Brandon Ferrua:
Yeah, baby steps.
Josh Birk:
Always a great idea when rolling out a new idea. I think I want to just level-set for everybody that’s like… This sounds kind of small in scope, but the reality is, this is kind of huge. People will be able to redesign and rebrand things to fit their needs and their logo and their brand and all that kind of stuff, and still get the benefit of the structure of the design system, the accessibility of the components from the design system. They get all the pros and removing one of the big negatives.
Brandon Ferrua:
Yeah. We see it as, especially from a long-term strategy perspective, it’s going to be a game changer when it comes to being able to kind of customize your components to your need. Because what we want to do is, we want to stop the… What do I want to say? It’s kind of like taking a hammer. We don’t want to have you smash through the component to kind of do what you want, right?
Josh Birk:
To force it to… Right, yeah. [crosstalk 00:22:15] square peg in the round hole.
Brandon Ferrua:
Yeah, we want to expose these services to our customers that enable them to keep the integrity of their component, or keep the integrity of a Lightning component that they might be using, and have the confidence that they can make those customizations that they need, right? And so though it’s, yes, our initial rollout is small in scope, I would imagine in a couple releases it will be massive in scope, and it will be touching many of our products and a lot of our verticals that we have within the ecosystem.
Josh Birk:
Well, and there’s an internal example that we can bring up, and one that everybody listening would be familiar with, which is Trailhead itself, like the website built on top of SLDS. But I think the technical term that I saw on a slide somewhere is that it’s working right now through lots and lots of tokens.
Brandon Ferrua:
Yes, lots and lots and lots.
Josh Birk:
So what are some specific advantages that the Trailhead team, the Trailhead design team could get from this?
Brandon Ferrua:
Well, I think what the Trailhead’s situation is, is they’re currently built on a platform not on LWC.
Josh Birk:
Right.
Brandon Ferrua:
They’re actually using React at the moment, the current product is. And so their goals and their intentions are, they want to use LWC. They want to use the benefits of that framework, and then also kind of move away from, I think, the bloat of their current implementation. Everyone wants to reduce your code size and optimize, right? And rightfully so. Trailhead should be fast. It should be easy for our developers working on that product to be able to kind of customize to meet the Trailhead look and feel, right? It’s very unique. Everyone knows what the Trailhead-
Josh Birk:
Right, right. And this would kind of allow them to keep those design decisions they’ve made with React and reduce it down to a subset of CSS that can just kind of [crosstalk 00:24:24]
Brandon Ferrua:
Yeah, exactly. So they can basically get a Lightening component or build their own Lightning component, and it will just come with the styling hooks baked inside of it. And so basically, what they can do is what we expect or essentially what we’re doing, is they can manage this a single source of truth. So they would just have their… maybe a single file or specific customizations kind of scoped to their components that they can have the confidence that their button’s always going to look like that Trailhead button, right? And it will be nice, succinct, compact. They won’t have to do anything crazy to kind of get it to work.
Josh Birk:
I think it’s interesting, and you probably have maybe a front row or second row seat too, because the nice thing about standards is that you get to see the not so far off future where the browsers are doing all the cool tricks for us.
Brandon Ferrua:
Yeah. Yeah, right? We can reduce our dependencies, right? We don’t have to have so much syntactic sugar on top of our LWC framework, because we’ll just have the browser kind of doing that heavy lifting for us. And it’s the closest thing to the metal as you can get, right? So it’s only going to make things faster.
Brandon Ferrua:
There’s certain things that we’ll want to provide that our customers can still take advantage of. You’re still going to get all of the security features that Salesforce has come to expect with the way that we kind of build or components, and you’ll still get kind of your data management and all that type of stuff. But what you get is, you’re just going to get a faster experience, and you’re going to be able to customize that experience way faster.
Brandon Ferrua:
And due to the fact that styling hooks is built upon CSS custom properties, you can use JavaScript to kind of change the value of that on the fly. So say you want to, you want to store your initial property in a styling hook for an animation and then animate that over time depending on how your customer is kind of experiencing the product. That will be easy to do, where that was really difficult to do before. I can’t stress enough just kind of the value and the benefits that just moving to a standards-based approach is going to kind of give our customers.
Josh Birk:
Yeah, totally. Side note, if I ever join a K-pop band, I’m going to insist that the name is Syntactic Sugar.
Brandon Ferrua:
Yeah, I like that.
Josh Birk:
And that’s our show. And before we go, I did ask Brandon after his favorite non-technical hobby. And once again, like a lot of people who are going through this age of the pandemic, well, he likes to get outside.
Brandon Ferrua:
I just had a daughter a couple months… Not a couple months. Nine months ago now. So I’ve been watching and raising her, watching her grow through this time at home. But in addition to that, I like to get out and stay active, so I’ve actually been… For a couple years now, I really got into running, which is like… Some people might think that I’m like a masochist, and like, why do you do that? But it’s something that I really enjoy to do, because I think with all the stresses that we got going on, I like to kind of have some alone time, and that is the perfect activity for me to do, just go on a nice, long run. And that’s something that I don’t think will ever get old for me, so-
Josh Birk:
Awesome.
Brandon Ferrua:
It’s something. It’s kind of weird as a hobby, but it is a hobby of mine, right?
Josh Birk:
Right, right. I’ve seen some people… It’s almost like somebody gets that one tattoo and then they have like a whole arm sleeve going on. I’ve seen people who are like, “Yeah, I’m going to get into running,” and then like two years later like, “Yeah, I’m going to do a marathon.” I’m like [crosstalk 00:28:21] addicted.
Brandon Ferrua:
Yeah. I did that. I did that.
Josh Birk:
Oh, nice.
Brandon Ferrua:
Yeah. It was weird. I try to do like a organized race when we were able to, or when they were still around, every month, so-
Josh Birk:
I want to thank Brandon for the great conversation and information. Of course, I want to thank you for listening. Now, if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast service. I’ll talk to you next week.