Episode Transcript

Ethan:

Hi, this is a Responsive Web Design Podcast, where we interview the people who make responsive designs happen. I’m your host, Ethan Marcotte.

Karen:

And I’m your other host, Karen McGrane.

Ethan:

And this week, we are doing backflips of delight because we are speaking with Jina Anne and Stephanie Rewis, who are here to tell us about Salesforce’s Lightning Design System. Jina, Stephanie, thank you so much for joining us.

Jina:

Thank you for having us.

Stephanie:

Yes Ethan and Karen, thanks a lot.

Ethan:

Well, we are so excited to have you both here.

Karen:

But first, let me welcome our sponsor, FreshBooks. I personally have used FreshBooks to manage my invoicing for many years now. FreshBooks has made my life so much easier by helping me keep track of who has paid me, and who hasn’t. It’s been a great product for years, but now it’s even better, with an all new version redeisigned from the ground up. Now it’s even easier to send invoices, set up online payments, and manage expense reports. Their dashboard, notifications, and automated late payment reminders will help ensure you get paid on time. FreshBooks is offering a 30 day, unrestricted free trial to our listeners. To try them out, just go to freshbooks.com/RWD and enter RESPONSIVE WEB DESIGN in the “How Did You Hear About Us?” section. They’re great, and you should totally try them out.

Ethan:

Maybe before we dive into the questions though, if we could just have you both introduce yourselves a little bit, and maybe one of you could tell us a little bit about SLDS. Jina, do you want to go first?

Jina:

Sure. I’ve been working at Salesforce for over five years, and the last three of those years on the design system. Of course, it’s only been out for about two, but we’ve been working on bits and pieces of it prior. Yeah, I’ve just been a total nerd for design systems pretty much my entire career in some shape or form, and pretty stoked that I’ve been able to work on this one, because it’s a pretty big one. [laughs]

Stephanie:

And I’m Stephanie Rewis. I am one of the principal developers/engineers on the design system, and I’ve been at Salesforce almost three years; I was hired as the decision was made to build the framework. So, I was hired for that purpose and it has been a freakin’ blast, I cannot even tell you. Super challenging, and we haven’t done everything perfectly, I’m always happy to talk about lessons learned, but it’s been a really, really great time working with Jina and the gang on this.

Ethan:

Well like I said, we couldn’t be more excited to have you both here. So as our listeners might have picked up, this is a slightly different episode for us because we’re usually here to talk about a website, some big production that’s gone responsive. But the Lightning Design System is—well, it’s a website, but it’s obviously a design system first and foremost; it’s a thing that builds other websites and other experiences. So Stephanie, since you mentioned the decision to build this system as kind of when you entered Salesforce, maybe we could talk a little bit about how SLDS got started. I’d love to hear what the thinking was in creating a design system of this scale and maybe some of the discussions around whether or not thinking responsively was the right way to go with it.

Stephanie:

Well, it really all started more with Jina and our old boss, Christopher, who realized after they had created the initial kind of smaller design system that people were really looking for a framework as well. They were trying to reverse-engineer what they had put up with the old examples and figure out how to put the CSS back together… That means the “C” in “CSS” does not stand for “cascading,” it stands for “confusing,” and so that was not the way.

And so once they had gotten the whole buy-in from our org to do this, that’s when I came on board, like I said. And so, Jina had already kind of done the inventory piece of it, going through zillions of designs, and she can talk a little bit about that. But I kind of take everything on from a standpoint of kind of an object-oriented CSS approach, or atoms—atoms, molecules, however you want to look at it, that’s how I like to build. So, I feel like that’s one of the easiest ways to start from the little bits and make something responsive—it’s easier to make it responsive, I feel. So, that’s how we’ve been building. We do use BEM because we have an enormous amount of developers that work with the system, and we feel that clarity is more important than brevity. Jina, why don’t you hop in and I won’t tell the whole story?

Jina:

[laughs] Sure. You were doing a good job, though. Yeah, so the first style guide we had, which some people saw when people like Brad Frost were showcasing it, which was awesome, was the Salesforce1 style guide, and that’s when I joined the team. It was a nice looking style guide, but as Stephanie mentioned, people weren’t able to actually use it. So, we basically pitched a CSS framework and to hire Stephanie, and we got her, and it was awesome. [laughs] That was probably one of my most exciting referrals that I brought into the company.

I’ll admit, there was a lot of pushback. We got the question, “Oh, if we’re going to do a framework, why don’t we just use Bootstrap?” and my argument was Bootstrap was solving a very different problem than what we were trying to solve. So, we finally got the buy-in to actually move forward. And to be honest, we had already kind of started working on it anyway, kind of went rogue. [laughs] Actually, it grew a lot faster than we were expecting, because we thought that this was something we were going to work on within the UX team for a little while, and then maybe in a year we’d get our third party open source community to use it, and then maybe in another year we would have our actual internal production teams using it. But that’s not quite how it happened.

Stephanie:

We decided to name Jina—we renamed her Khaleesi, because she got this idea, and it was this cutest little dragon egg and it hatched and it was adorable, and then it just turned into this giant flying creature that is eating us alive… [laughs] No, not really. But it really did happen like she said. I was basically worried about our prototypers and our external developers, and not really worried at all about platform, because everybody basically told me this probably won’t—we might get a button in in two years. Well, it didn’t turn out that way. It got extreme buy-in. It went up the food chain, through UX and into the org like something I’ve never seen. I think our boss must have been doing a great job selling it, I don’t know, I was not involved in that part.

But I will say, it went up the food chain, it got buy-in, and I had to start pushing back. I was hired, started the first of February. By April, we realized we had to have another engineer and we hired Brandon, who we work with. And they wanted to put it into alpha by June… [laughs] And I said to them in the meeting, “Excuse me, I love that we have all this buy-in and everybody wants it, but we have to build it. So, yeah…” So I think we got the first bits of alpha out by July, and then we went beta by Dreamforce, which I think was late September. And then within, what was it Jina, like a month after that they started putting us into product?

Jina:

Yeah, I think so. That sounds right.

Stephanie:

Yeah. And I don’t know if we’ve ever told anyone how fast this went, because we were almost embarrassed by how fast it went. But the problem with going that fast, though, I will say is you’re making decisions that you thought you would have all this time to architect, and you’re having to do it really fast. I can show you were the “bodies are buried” in the framework, and most of those bodies are because of the speed we were building at, really. But there’s a lot of good stuff in there too, so.

Karen:

Jina, let me follow up on something that you mentioned, which is I think very interesting to both me and Ethan. One of the things that goes along with responsive design and the idea of designing for all of these different device types is the idea that many organizations are using a design system as a way to help them do that, and sort of naturally I think people start to equate a project like this with using a framework like Bootstrap. So to your point, that you thought that Bootstrap was trying to solve a different problem than you were trying to solve, could you talk a little bit about what is the problem that you’re trying to solve here?

Jina:

Yeah, of course. So when I looked at frameworks like Bootstrap and Foundation, I think they’re really great for getting up and running, especially if you don’t have a big designer/dev team. I’m not going to get into a debate about whether Bootstrap is production-ready or not, but it’s not something that I felt was production-ready for what we needed. We have a lot of different features that we have to be able to account for that I didn’t feel Bootstrap at the time could do. Some of those features being we’re looking at varying sizing and spacing across products. So, most of products have one set of spacing, but then our console, which our customer service reps are using, is going to be a lot more condensed because they have a use case where they need to see as much about the customer on the screen as possible. We also have customers that want to brand their UI, they want to be able to move things around and configure things.

Some of the things that we’re looking at now is switching over to a different theme, switching over to night mode, cozy compact comfortable settings, all of these different things that we kind of needed to build something very unique and custom to us to be able to account for all of those. So yeah, at the time we were really ramping up on our Design Tokens, which if you’re interested, I can go into more detail on. That was sort of the—sometimes we’ll call it like the sub-atomic part of our framework, and it drives all those features as well as our framework, as well as our native platform. So with something that unique, it didn’t make sense to adopt somebody else’s framework to do that.

Stephanie:

We’ve sort of taken the idea that we build things as we need them. So, for example, we don’t have a carousel in our framework, because for platform we haven’t needed a carousel. We try to keep it as small as we can, and we do this thing called standards reviews, which designers will bring us their ideas of what they’re building, what their feature is going to be, and we’ll look at them from a pattern standpoint, we’ll look at them from a kind of what is already in the framework and what can be reused, and then we will look at them from the standpoint of accessibility. All of those things happen before the designer has completed their final design. Then we build from there. I think that essentially knowing, okay, we need a slider now, great. Okay, now somebody wants a green slider, then, cool, we’ll allow a variant that will turn the slider green. But we don’t just put a slider in because every framework has one.

Ethan:

If you both don’t mind, I’d love to hear a little bit more about that decision-making process. I think one of the challenges a lot of organizations have with design systems, at least in my experience, is understanding when you need to introduce a new module, or when you need to update an existing one. How do you actually decide from day to day what gets into the framework basically, and who’s responsible for making some of those decisions?

Jina:

It’s a shared ownership. Historically it was mostly our team, but having a team making those decisions and being the governing team, but also maintaining the framework and also maintaining the website is kind of hard to scale. So, we’ve adopted the shared ownership model, where we do have a foundation UX team that is super knowledgeable about all of our patterns and components and guidelines. But we don’t want to put it all on them, either; we try to distribute this information to everyone and have everyone contributing back. But when it comes down to a final decision, those can be made in those standards reviews Stephanie was talking about. And I think that’s the only way we can really scale and grow this and keep it living, is by spreading the ownership across the team.

Stephanie:

Yes, and we’ve kind of moved into that direction because we did make a mistake at one point. We had added a wizard kind of component, these little steps, and the team that had us add it did some research and decided to change the design. So, we went ahead and changed the design because we hadn’t released it externally, so we didn’t deprecate it, we just changed it. What we didn’t realize is that internal teams had already built it using the previous wizard, and then people are telling us, “Well, we really liked the previous wizard. We like that design better.”

So then we had to look at, okay, who really owns this design? Once it’s put into the design system, does the team that asked us to build it get to change it, and then it changes for everybody? Or do we do a V2? Or does it get discussed with the foundation UX people? That’s kind of how we got into a little more of a distributed model so that there were more eyeballs on things, and we, as a very small team, weren’t making decisions like, “Oh, sure, we’ll change your component.” Because it isn’t any longer their component, it’s now owned by a huge system of clouds and external developers. So, we learned we had to be very careful about things like that.

Ethan:

That’s really great, and it makes me think of one thing that I’ve always really admired about SLDS, which is the guidelines, the design principles that are kind of baked into it. Because this is something that I think a lot of organizations pay a little bit of lip service to, like, “Oh yeah, we have some design principles.” But this is an extensive section of the document, and I’d be just kind of curious to know how they got introduced into the design system and when, if any one of you wants to speak to that.

Jina:

I can speak a little bit to it. So, we built the Lightning Design System in conjunction with also building the Lightning Experience, which was the desktop UI that we were refreshing, and Salesforce1 was specifically our native mobile and tablet apps, but those apps also brought in some of the Lightning look and feel, as well. So we were basically redesigning Salesforce at the same time as the design system, so we needed a way to have an order of operations when it comes to our design decisions, because we could talk in circles all days and for weeks and months and never ship anything if we’re not careful, so we needed a way to really solidify, okay, this is our priority, this is how we will come to a decision.

So, the four principles that we have are clarity, efficiency, consistency, and beauty, and those are in a very specific order. So when you’re having an argument like, “Oh, we can’t change it here because then it’s not consistent,” you could argue, “Well, it may not be consistent, but it provides better clarity and better efficiency,” and so in that case that would win out because those are more important to us. So, this has been super helpful not just from designing new components and new features, but we’ve even taken it into account with how we write documentation, or how Steph architects most of the CSS. We find it’s not only awesome for our team, but as I’ve talked to other companies that have design systems, they seem to land on pretty much the same set as well.

Stephanie:

Yeah, and as far as the design guideline section itself, that has been in in some manner or shape since the very beginning. Most of that section does come from the UX designers and the foundations team. Or sometimes somebody will have done a huge feature and they will give us the guidelines. Sometimes the decks we’re building a component from, I’ve had them be as big as 150 slides. So it’s very hard, as a developer, to write our own documentation for that creature when there’s so much detail in a deck. So we typically get the designers to help out a little bit with that piece. And I will say, we try to also do developer documentation. That’s typically done from us, sometimes with their help, and we got a little bit lax about it when we were building really quickly, so we’re really trying to make that be a super important part of definition of “done.” You probably know that Nicole Sullivan is now our boss, and so that has been a really exciting addition to kind of have her eyes on it post-building. We’re doctoring some things up coming up, but she is very into wanting to get everything great for documentation, people that are getting started, and stuff like that. So, that’s going to be a big effort.

Karen:

I’d like to ask about a subject that’s kind of near and dear to my heart: how do you provide guidance or training or any sort of direction to the teams that will actually be creating the content or the messaging that will sit inside some of these components? One of my concerns about our industry has always been that we tend to put a lot of emphasis on the design process, we have sort of a head fake in the direction of, oh, and then somebody else is going to fill some words in here, and that that’s something that can be relatively easily replicated in a component-based design system. How did you deal with that, or how do you deal with the people who are putting the words in?

Jina:

So, we do have help from a team that focuses on documentation and UI copy. I’ve forgotten the actual name of the team, it’s like the doc team, I think. The designer, however, usually will have a lot of say in what the copy is through user testing, and so oftentimes you’ll see a back and forth between the designer and the doc team. And sometimes the doc team will make suggestions, and sometimes that suggestion you might think is not really the best suggestion because they’re going based on their experience rather than actually using the product. So, what you could do is actually bring that doc person to the research testing sessions and then they can see, oh, okay, this is actually how that’s supposed to be used. And then we also have a lot of guidelines around things like truncation, when is it proper to truncate and when is it not, and that actually came all from the doc team. So, that was like a pretty awesome outside contribution that came into our system.

Stephanie:

And another piece, as well, is localization. Because Salesforce has taken to so many languages, we got involved with the team that does that localization and we tried to bring those guidelines in early, because what was happening previously is people would build it, and when we get the designs, Karen, they don’t have lorem ipsum, they try to make it as realistic as possible so that we can kind of see how things will work. But then what they weren’t thinking about until the end of the process was this localization piece. So, the people doing that would have these bugs they would have to file because somebody wouldn’t realize that, in Russian or German, these words that were in the buttons were going to get really long or whatever; they weren’t thinking about those things. So, what we’ve done is we’ve tried to bring that in really early, and given the designers’ guidelines to think about for things like that, as well as the localization team built this little plugin they can use in Sketch, it will fake localize, it will make words longer, it adds characters, and it kind of uses—there’s a formula you can use, if you have this many words, it’s probably going to get this much bigger. But we try to get the designers to actually use that plugin, test their stuff, so that they will know what will happen when it gets localized. And we have other rules, like we try not to build things like three equal height boxes—unless we’re using Flexbox, of course—things like that. We try to educate designers on what’s best practices for these things.

Jina:

Yeah, and another really cool thing I’ve been seeing is we have a sister team that focuses on prototyping and doing exploration-type magical stuff in code. One of the things they’ve been exploring is if you spin up an org of Salesforce, basically your own version of Salesforce for designing and testing, there’s a lot of fields that you have to fill out to get it to feel and look like a real org, and it’s just not really humanly possible to do that within a quick, short amount of time. And so they will populate an org with real-looking data, and they’ll even explore real-looking names paired with real-looking addresses, and it’s really cool to see what they’re doing just for prototyping purposes.

Ethan:

Well Jina, Stephanie, it has been wonderful having you on the show. But before we let you go, I would love to hear if either one of you has any advice for our listeners. If someone’s out there listening to this episode or reading this transcript and they are about to start their own responsive redesign, or maybe they’re trying to create their own design system, do you have one or two things you’d like to share with them on things they should try to do?

Jina:

I guess the biggest takeaways I’ve learned from this process… Definitely if you ask for something to happen, people are probably going to push back. You’ve just got to show them. That’s basically what we kinda did; we started working on it, people saw it, and then they wanted to use it.

Stephanie:

What have we learned… We’ve learned so much, there’s a lot… In fact, I have a whole talk that I wrote, kind of a “Lessons Learned: How to Not Lose at the Chess Game of Design Systems.” One of the things I would advise people is know as much about where your code is going to go as you possibly can. One mistake that I made by not paying attention to platform and where this code was going to go was when you use BEM, the most common BEM naming is the double-dash form. And we used that, that’s what I’ve always used, and we have XML in our platform, one of the steps, and you cannot comment out XML with double-dashes, or you can’t comment out double-dashes in XML, so it would throw an error. So we had to literally change our BEM mark-up to be the single underscore instead of the double-dash. So had I found out everything about our environment before I made those decisions, that would have saved a big piece of pain. So, it’s really important to kind of figure out everywhere you might go.

Another thing we did was we built for platform, so we zeroed out heading margins… Everything is very tight on platform, and so we built with that as our base. Then what happened is the adoption has been so great that they really want to use it in a more editorial form now. So, sometimes you make decisions that are right for where you think you’re going, and then you grow even beyond that. So, there have been a lot of interesting things, but mostly to do with figure out every place and every situation your stuff may go into and work from that, even if you think it won’t go there.

Jina:

The distributed knowledge, you don’t want to have “tribal knowledge” happening… Because we actually, just last week, had one person on honeymoon, another person broke their leg, another person was out… If only certain people know things, then that can be really bad. So, we’ve been really pushing towards getting everybody up to speed on all the things as quickly as possible and sharing that knowledge with each other so that we can all support each other and move more quickly.

Karen:

Well, I have to thank you both for such an interesting and lively conversation today. I think, as Ethan said, we’re both huge fans of the Salesforce Lightning Design System and I’m really happy that you told us a little bit more about it. So, thank you.

Jina:

Thank you.

Stephanie:

Thank you so much for having us. It was a blast talking to you.

Ethan:

Thanks to everyone for listening to this episode of a Responsive Web Design Podcast. Thanks also to our sponsor, Freshbooks. Go to Freshbooks.com/RWD and enter RESPONSIVE WEB DESIGN in the “How Did You Hear About Us?” section for a 30-day free trial.

If your company wants to go responsive but you need help getting started, Karen and I offer a two-day onsite workshop to help you make it happen. Visit responsivewebdesign.com/workshop to find out more, and let us know if your company is interested.

If you want even more from us, you can sign up for our newsletter, subscribe to this podcast, and read full transcripts of every podcast episode at responsivewebdesign.com.

Thanks again for listening, and we’ll see you back here next week.