If change isn’t built into the process, a “Living Design System” can’t evolve. In this talk we'll discuss the lessons learned, and the challenges faced, as our system went from crawling to running. Refactoring, versioning, and deprecation are but a few of the growing pains we've experienced on our journey to build a stable but incredibly flexible Design System.
Chris Coyier:
One time, I used to live here, not long, I was having a party at my house and Steph was in town and there was lot of people around. And we got way to drunk. Don't drink, that was in the past, and I had a head of hair at the time. And I was like a little sad with myself, and I never do anything with my head, I have a kit and it's done, and I wished I could do more interesting things with my hair. And you know what I wanted to try, is the thick Mr. T deal, and I thought, maybe I can pull that off. Make I could try it. So Steph was, like, let's try it here in your party in the living room and they did it. And they carved a good job. But it was bitter sweet, because I'm a little too bald in the back. Steph is a sailor, and they are going to sail around the world. They will talk to you about that at the after party tonight. Stephanie has a lot to say about peas in the pod and they work well together, and she told me last night, they often use the Cat Watkins thing. If you are talking about something, with somebody, and there is a little disagreement, how many fruits do you give? Do you give four fruits or seven fruits? And seven fruits win. That's a great way to solve any argument gnat professional setting. They will both talk, but separately. So Steph will come up. Please welcome Stephanie
Stephanie Rewis:
One mike will do. How is everybody doing? Are you sleepy after lunch? I'll shout. I would love to know how many of you are actually working to pattern library or design system? How many of you are here to get some ideas and talk your boss into it and take your company there? Less of you. Lot more of you in it already. How many of you feel like you've nailed it. There is a guy in the back. Good for you. I'll talk to you later. Today Brandon and I will share our journey and implementing, C S S framework. It not perfect, you can blow it apart. Miriam had a great things to say about our icon naming. It's an evolution. I'm required to show you this. The moral is if you make any stock purchasing decisions today based on a design system talk you need to see your therapist tomorrow. Let's talk about C S S and design systems. When I say sales force what do you think about? C N N anybody? That's what I thought when I went to work there a little over a year ago. But when I got there I realize there was a whole lot more. We have tons of clouds and dish did we need a design system? And we needed a framework in that design system. It was a big challenge. It was compounded with a fact that we were launching the lightening experience which was the first time in 17 years that the system was over hauled. Lightening is a big team. It's a large team of U X designer the. We have a small team of designers and we have a code base which has been around sense bill Clinton was president. So after this evolved we had people fleeing into the abyss. I was a consultant hired to build the first system. The C S S was additive. Everything cascaded into everything else. And specificity battles ensued. They didn't love these battles. A lot of multiple directives. We had to make this thing work. First thing we needed to do was learn to crawl. In 2013 we launched sales force which was our mobile app. And then we took the first step toward a living style guide. And it was a great first step but a year later in 2014. They were able to talk to partners. They heard that partners wanted their stuff to look like sales force. There were over a million sales force users. Our static guide We found that people were reference reverse engineering our C S S guide. What developer doesn't want a good copy paste. So it wasn't just external partners that needed our help. We had internal pattern partners too. We had the goal of having them design in the browser. We had launched the lightening design system as you know. It's our evolution to try to meet those needs. We had numerous patterns. For now Brandon we are concentrating of C S S framework of the design system. We eliminate the need for red line specks. He engineers don't have to write code they can cut and paste. They did a huge amount of taking all the comps for the various designers and inventorying all the components that they had created and as you can imagine, font sizes, shades of blue, spacing were very inconsistent. They established patterns for fonts, for spacing for colors and then the designers would put it them back in the specks. And then to make them more resilient we turned them into tokens. They are constants that are equivalent to properties. These are some of the ones we offer. We create the tokens. From mobile tokens and tokens used by our own developers. Here is an example of Sass. The beautiful thing about this is we can make painless changes to the C S S so if our borders change, and it's no longer four pixels, we can change it in our variable and everything gets the work for free. And it allows internals to use our own branding. This is the same thing, but different format. Our design audit, alignment and our tokens allow us to build with a more efficient way of C S S. This is going to sound familiar to many of you, using A O O C S S idea, we looked for the smallest atoms and identified the pieces and patterns building from small to bigger and combined them to make larger components. And one of the first decisions we needed to agree on was our own naming conventions. Clarity was important. And we chose to use Clarity to make sure that our class names were understandable. They are explicit, and they are verbose bit they are much more easy to understand. Clarity is an important principal. Another way we make things clear, you probably know what it is, it makes naming easier for a large group the developers to understand, it's much easier to look at the class and know exactly what the class is, it's a piece of an another component or a variation of a component or of a block. Keeps specificity very low which was super important to us, where we don't end up with these wars where they go higher and hire. We needed the B E M convention. Take the goods things and use what works for you. We learned a couple things, one is that naming is really hard. Do you ever get stuck? What is this thing, should I abstract it more? That's hard. One of the dumb things we run into, is B E M orphans. We had seen this problem with we had these B E M components and then we didn't realize, and we had to refactor, and then there was overlap, so it seemed really dumb to put a class on to show over flow and hidden. So these became stranded class that had no block, mama. Shit happens. That was a lesson. BEM has some other interesting challenges. At sales force our core platform, and X M L has very strict results. BEM naming uses double dash. Guess what you can't have in an X M L comment? A double dash. It's illegal, and what happens when someone comments out a bit of code in their X M L is this and it won't compile. Much wrath from developers was hurled at us. We are open. We have a nasty hack going on that involves C data. We would love solution. This is a weird one that we hadn't thought about in the naming. As we learned to walk, we found that enterprise applications have some unique traits. This was in our own audit. We found that with content, it's very data rich, applications don't really interfaces that. We don't know in an enterprise application framework, where the planner has to use these things. We want to developer to use the proper semantic in the heading. So we equalized all our headings. We created text utility classes placed on, to get the same heading look. And we only have five heading looks. So we get the proper utility on them. To get the look we need. Lists are used for their semantic. So we removed all the list markers and padding by default. But what if somebody is doing a feed. Or something that is a little more in an a composer, there are a couple ways they can opt back into spacing. You can have a utility class, or you can wrap a group the elements, headings, and paragraphs, in a wrap that restores the normal spacing they would have. Another big focus for us is accessibility. It's a mandated sales force, I love that. So we banked accessibility from the start. So we use the proper elements so we can do that. And we show instructions in how check change. So REM unit is fully sized. They can hit browser zoom and had zooms any away. People running around the web, they don't always hit zoom. I have an aunt with lupus. And word in a component that isn't sized the right way. If you read down it's uncomfortable. When you have somebody who picks a 32 font size, we have an all scale to fit. We play well with others. Say you might have a framework, with .button. Maybe it's an old bootstrap, and my developers are transitions over from that, we are in a together to start. That causes cascade conflicts. So S button became S L D S button. We might not have normalized scaling. Scaling our components down to three quarters of their size, we had to create a method of scoping to take it one step further. You basically use scoping with our components with the domain is out of your control. And you can put a class either on the outer wrapper of the component, and S L D S class, and this basically raises the specificity of the element selectors and make everything in varying environments work out so let's say they used an L U L L I, we win a war there because the class a higher, so the elements there are protected. And this protects them from our elements as well. So my right hand man, who sits right by me will talk about how we evolved some of our ecosystem.
Brandon Ferrua:
Part two. How will we learn how to run a little. Probably more like jogging at this point because we haven't gotten to full sprint yet. Let me walk you through that journey of what we went through to get to where we are at today. I'm sure a lot of you have heard the term, if you build it they will come. It's a pretty heavy handed quote in my mind. A loot of confidence there. We are building this awesome thing but how are we going to implement it at a scale like sales force. It's a very big company. So there are a hand full of questions that we continual ask ourselves along the way. How do we keep the bar extremely low for adoption. Like I mentioned before, with the size of sales force, I don't know how many clouds we have, that's something we have to keep in mind as we continue to build. The next question that continued to be brought up was how do we maintain a level of consistency. Consistency is usually raised around the topic of consistent visual design, right? Makes sense, I think a design system a solving a portion of that. But from a framework perspective or the framework portion was the design system, is the implementation. And lastly, this is something that we kept asking ourself and we had to keep going back to it to make sure we are right. Which I think we still are, how do we keep the system agnostic and stay agnostic and not give in to a lot of the demands of the particular developers. Because we are dealing with external as well as internal developers. So staying agnostic was super important to us. So with those questions in mind, we knew one thing, which was a key to kick starting the design system to be accepted was to minimize your product development. There is a thing called M V P the minimal viable product. So end product, minimum, we focused on that, by doing that we kept things simple we didn't over complicate things. We didn't say we will support this stack and this stack. So we felt pretty good about this. But then, I'm going to lead into a lesson learned here. Even though you might fell really really good about something in your design system, something to keep in mind, is you don't know what you don't know. You really don't. There are things we learn every single day, and it might be because of the scale of sales force, you have to understand what your ecosystem is, that you're building a design system for. You have had to understand your customers. And unless you can see the future, which most of you might not be able to. Just try to understand where a potential footprint is. Because once you build it, and you try to support a certain version of one of the million libraries out there, you will have to continue to support it. Don't be a victim of your own success. And understanding, I think these three bullet points here, really allowed us to make the correct initial decision and then also giving us the flexibilities to adapt along the way. Anyways. Lesson learned. Hopefully everyone got that. Back to where we were at. The minimum dependencies we are focused on were tokens icons and H T M L and guidelines. It's what people knew, it's a good starting point. The foundation of what we wanted to system framework to be. You might notice there is something missing. There is no java script. Crazy. No java script today. But I'm a react building. It's so cool. This was kind of a key thing for us that I think allowed us to keep that bar extremely allow in a company like sales force because it allowed us to continue to stay agnostic to what we believed in. And the decision to not provide java script provided a lot of flexibility for us. Just to touch a little on why we didn't include java script, there is a lot of technology that we knew of that sales force developers wanted, the top is that we have our own proprietary java script library. That is one library. We didn't want to play favorites. Because java script manipulates the way components and the way of the user uses it. We relied on the information architecture in a documentation. Like Miriam was saying, if there is no documentation there is really nothing. So documentation is super important and we definitely believe in it. Even though we might not want to write it. But we definitely believe in it. So we kind of took the information architecture we have to the site and introduced the concept of states and variance. I'll show you a little what that looks like. Here is the lightening design system. And we're on a publisher component. And we are using something like a discussion group. On the right hand side, we have what we call a component navigation and what it does is it lists out the variants and then we list the potential states that the component maybe presented at. It maybe manipulated through user interaction, through particular data introduced in the component, but we built a framework that allowed us to define the states on a component by component basis. Then I click on this, and our live data, notifies the developer what kind of classes have been removed. Or manipulated. We love documentation, but I still don't like writing it. With a we have done is underneath the component we list out some documentation that provides guidance to the developer that shows how to properly implement the java script through the user experience. What we expect to have happen based on the experience of that particular component. So we provide that. So we take it a little bit further. Like Stephanie mentioned, accessibility was number one in sales force, we document all the access elements that need to be added. And what can be manipulated based of the information that the user can invoke? Next I want to move on we have jog in there a little bit. We feel good about a low level of dependency. Buts there are some potholes we have to jump over or trip in and I'm going to talk about throw avoid those. The documentation we're going over has a big problem, and it's the fact that it's written. And when it's changed you have to rewrite it. So it's not good for the consumer or for the consumer using an older version. So as a design team we have to support all three. Currently we have our current production release. This is what we provide to both internal and external developers. This is what we will use in the next version of the platform. But we don't want to believe anyone behind so we have to support the previous version of the production release and with that comes a little bit of maintenance but also the design team has to provide a migration path to get them on to the new version and the most exciting release and the future production release. We are always in development and we also might have, maybe even two releases that we are working on top of the two previous releases I was talking about. This is an opportunity for us, for these future releases to sit down with individual designers and work with them to figure out with a kind of new patterns we may need in the design system or what kind of component we had in previous versions that we need to revisit and update. Because this is baked into the ecosystem that is going to evolve over time. This leads into deprecation. Very common technique in software development. I had some questions around with a deprecation, meant, to front end developers, as a developer after the framework, these are some of the top questions I had. How am I going to keep track of my changes over the span of four releases that we are maintaining? When might be the right time to replicate? Now I backed out, and now I'm back. As a consumer, I have another set of questions. How do I know when something is deprecated. If I'm using your framework, or your design system, whether is this thing going to die? Obviously we don't want things to die. About you if we do need something to die being because at the end of the day, we don't want this thing to grow into a beast that is unmaintainable. At some point so many things need to pass away. That leads me to discussing what we have on our side. We had this on our pages a thing called component table. Here we list out all the available classes that can be applied to a particular component that can provide a certain set of outcomes. This can be element classes, java script classes, everything you can think. But, so we thought utilities this table was going to be the end all. But it doesn't really work for us. It wasn't ideal. It caused, it caused the developer to do a little more searching on the website, it wasn't presented in from them. We thought about this, we thought what we do with the tools at our disposal. We are developing with Sass. So we decided to come up with this thing called Sass deprecate. It might not work for everyone. The way it starts, is you I'm sure a lot of you are familiar with the concept of December. Or node. So it's a patch, so we applied this to our Sass files. Whether I release happens, either a minor or patch release, this number is updated. It's pretty flexible. So we took that and asked what can we pass through that number to get our code. We need a version, that will trigger it to deprecate. So then we have to tell the person why we are deprecating it and what to use. So here we start by simply just providing the app version of what we are currently in S. So in this release we are introducing a button icon. But in version two, we want to deprecate this class and then warn it is developer that in version three of our application this class is going to be no longer compiled. So there a couple advantages to this, it gives the developer a defined number versions before a change. So we are buffering them. We are helping with the migration process. That's why I message is to important. My favorite part of this feature is you don't have think about it. This deprecation feature is throughout our code. So when we update to a certain update, that code is gone. So it could look like this over time. So it will allow your code base to not become bloated. If your design system is so dig on the ecosystem, you don't to be on the blue path. You want to be on yellow path. I encourage everyone to which can it out. The design system is open source, so you can see how the code is used in a production environment. With that said, go for it, and deprecate some stuff. But do it with a little bit of confidence. Don't be scared. That's it for us. I want to say one last thing before I get off stage. We are currently layering right now. So if you want to work on a project like there with me and Stephanie and Gina, and Han. Please come feel free to grab us and we can discuss it. Thank you very much.
[Applause]
Chris:
If you sit in this one, it might break. There is a bunch of cookies, and you should eat one if you are unaware of the that. All right. That was the look at lightening that I wanted to have in a way. Theo is one of the names of it. It looks like Jason, but it's a language you invented? It's preSass?
Stephanie:
It's J song.
Chris:
It's the idea that, I don't know, some of our properties use your internal thing and it's not Sass. Or maybe we can compile it into a metalanguage. Blow that.
Stephanie:
It's subatomic.
Chris:
Is that part open source?
Brandon:
It is.
Chris:
That's worth having a look. That's the reason to have a design at all, if it works across the applications. If you make a Sass one only, you are limited to the web I guess. You are excited about it.
Stephanie:
I love the web, Chris.
Chris:
Good, but other things too.
Sometimes I look, H T M L, is there are some many names, do you think class names need to be forever or are you reevaluating class names as well. Sometimes it freaks me out when I see 50 class names.
Brandon:
We don't want to go down the line of single classes.
Chris:
How do you approach a new platform. You are not afraid of underscore underscore small. Is that a thing?
Stephanie:
No that's no, the thing. It would be dash dash. Gets your BEMs straight. Truthfully it's a debate we have. We do have utility classes, you can put margin on the side. Or you can put them on a component. It's a debate sometimes. Looked at building a component where do you we want to build an extra class, or where do we want to build a component?
Chris:
You can go heavy handed in one release, and nowoff way to back outs of that choice.
Brandon:
That's how that's been used up to this point. Where we, in an a couple of releases got a little heavy handed with say embedded utility classes on a certain component.
Chris:
Can you train everybody in, I like it is idea of the yellow path we put, so the thing won't blow up over time. So people won't be afraid.
Stephanie:
To be perfectly opaque. Or clear. One of the reasons that really caused Brandon to come up with this deprecation idea was whether we were rolling from one version to another, we realized that our sales force ecosystem had adopted this so rapidly, we expected to be used for prototypers and developers and then suddenly we were going into core. Do you put a dash or dash wrapper? So we came up with an idea of coming up with a single under score. So then we needed to go back and in a case everything consistent. So we locked ourself in the room called the library, and we spent the week there refactoring everything we knew we wanted to refactor before it get more difficult. So.
Chris:
So the more you deprecate, is there a danger of losing trust with people.
Stephanie:
They would kill us.
Brandon:
Hopefully we won't get to that point. It's a part of the culture, where being a part of the design system, we want to lend that helping hand to make sure everybody is following the proper migration path and we walk the developer or consumer through that.
Chris:
Is it a consumer warner where you see that?
Brandon:
There was a it spits out in your terminal. And they will notify you. We found deprecated code in this spot.
Chris:
Is there somebody on your team who is Benevolent dictator here?
Stephanie:
Not really. I think we have developed a good level of trust already. We sit down with that you are developers. And we try to point them to problems we already have we don't have an overlord really that is forcing things in.
Chris:
We have team agreement are what goes in and what does not? That's a little bit of the part of the talk.
Stephanie:
We have some challenges with having different clouds that have different requirements and we have some evolution decisions to make about how much of those different bits go into the design system if it's only one cloud that need something specific. Those of challenges were trying to solve now.
Brandon:
Special snow flakes.
Chris:
The metaphor you used for both talks to guide them together was the crawl walk run thing. It's a pretty good metaphor for any of us to use for any design system. You have a different crawl than you had a different walk than you had. There was also different failures that you had. I wonder if there were any failures that could have been prevented.
Brandon
I think it was like the lesson learned we put out there. It's like who you are going to be touching.
Chris:
The crawl was who.
Brandon:
The stakes are inevitable. Mistakes are there and learning to adapt is life.
Stephanie:
The thing that keeps me up at night is okay, we have built this thing, and it's being embraced and very successful and now it's being adopted by a ton of different ecosystems.
Chris:
Sales force, internal and external, and is there external external, what if I wanted to use it? Would you listen to me?
Stephanie:
Well, because of our font, that's the only the reasonable reason it's supposed to be hosted on a sales force property. If you took the font out, you could use anything you wanted. We are not bootstrap. We are not trying solve anything but sales force ecosystem patterns and issues. So you probably wouldn't want to.
Chris:
The fact of it is interesting we can look at it. But it not please down load this.
Stephanie:
I have heard of other people building applications that are using it. I don't think they are supposed it.
Chris:
People think of the documentation in an a different way, this is one is generated by Sass dot. And you can see examples, your documentation includes human written paragraphs explaining things, which is a whole different level.
Stephanie:
We hate this. When we love it. Painful to write.
Chris:
And you write you would write this in this circumstance.
Stephanie:
And now that Greg is working sales force, he is showing me at home, while we are working, Stephanie, this is piece of documentation is missing S and I said, we will give you writes, and you will write P R, and I will accept it.
Chris:
I was thinking, how long has this been around ask dealing with deprecation, and you handled that well. And there are people who struggle with that. And the growing line.
Stephanie:
We never said we weren't afraid.
Chris:
What are you scared of?
Stephanie:
For us now that we are in core especially, there is a lot more pressure. We agreed to, it's sort of case by case. We will have things that won't be deprecated. But we have others that will have to be because they have evolved.
Chris:
Seems like a dreamy job, right people? Thanks for talking to me. Let's do the thing where we hang out for six minutes and then proceed for the final.
