Design Systems: Real Talk

Design systems have been around for ages; you can see a little bit into the history of them as brand systems and graphic standards manuals of the past are resurfacing as collectibles today.

However, in today’s modern web and software design industry, there is no denying that design systems are so hot right now. People are making them, sharing them, writing about them, and talking about them… even forming entire teams dedicated to working on them. It has been exciting to see the traction they are gaining, and how far they have come through process, automation, and tooling.

It truly can be a dream product: a design system that scales across many enterprise products, many devices and platforms, and is open source to a larger developer community. What a fun challenge for systems-minded designers and developers. And starting out, you have a pretty good idea of what the end result will be.

But at this scale, there is no end result. There are interesting challenges you will face along the way: internal politics, design changes, business decisions, configuration, deprecation strategies, naming, adoption, onboarding, support, training, governance, resistance… There are implementations and then undoing of those implementations. Enterprise design systems aren’t easy.

But don’t let this intimidate you. There are always lessons to be learned and shared. And we as an industry are constantly iterating and improving on our processes. We’re all in this together.

In this session, Jina, a design systems designer, fan, and advocate — and who was Lead Designer on the Salesforce Lightning Design System — will share some stories and insights into the lessons she has learned designing one of the largest design systems in the industry.

Transcription

Audience: [Applause]

Jina Anne: Hello. Or should I say, “Hallo”? We just had a photo shoot at work for headshots, and this was my favorite even though it was an accident.

As Marc mentioned, I do work for Salesforce, and the product that I work on is the Lightening Design System. But before I get started talking about all that, I wanted to say thank you to all of you, and thank you to Marc, and thank you to everyone at the event because I’m really excited to be here. I’m really honored to be here. I’m super jetlagged though, so bear with me.

Yeah, so design systems. Anyone that knows me knows I really love design systems. I’ve been kind of evangelizing them for quite a good part of my speaking career. When people say “design systems,” there’s a lot of different things people think about when they hear “design systems.”

I love collecting mid-century design systems like graphics standards manuals from the ‘70s. Probably the two most well-known ones that are re-released right now through Kickstarter are the New York City Transit Authority as well as the National Aeronautics and Space Administration, otherwise known as NASA.

But these days when people are talking about design systems, it’s usually in the context of software, product design for the Web, and so some of the really well-known ones that have been out lately:

• Apple has their HIG or Human Interface Guidelines.
• You’ve got Google with the Material Design Guidelines.
• You even have Lonely Planet with Rizzo.
• You’ve got Harmony or Intuit with Harmony.
• The United States government basically has a design system through their agency known as 18F. I’m a huge fan of the work that they do.
• The one that I work on.
• There’s also Carbon by IBM.
• You’ve got Polaris through Shopify, and Microsoft just announced theirs, which is called Fluent.

Lots of companies are putting their design systems out, and they’re kind of like all the rage right now.

I just want to very briefly kind of talk about how I got into them and why I love them so much. My first style guide that I created was as an intern at a design agency in Memphis, Tennessee. The agency was called Odin, and it was basically there’s a card game called Bridge, and it was a group of basically bridge players, and they were redesigning their site. I made a style guide for it and, in the style guide, I was documenting brand. I was documenting the CSS. I was documenting grid, all that stuff, but this was done in Cork.

I know. You probably haven’t heard that word used in a while. It was done in Cork, and it was output as a PDF. Obviously not the type of design system I’m going to be talking about today.

The next one that I worked on was when I was at Apple. I was on the online store team, and we had a lot of different shared patterns and components, and so I was starting to document this type of stuff. It got me really interested in doing this for the Web. So much so that I shared my excitement on A List Apart. But even when I wrote this, I was kind of really still dealing with PDFs or dealing with Wikis or putting them on, like, a WordPress.

I also worked at a design agency after that where I was doing a lot of brand guidelines for our different clients at Crush & Lovely. But it wasn’t until I worked at Engine Yard, which was a Ruby based company, that I really started exploring putting these online. This was also my first time using Sass.

I used to write CSS and think that I didn’t need Sass, and so I was learning Sass, and I was starting a new job at the company, so I wanted to really learn the UI. I was documenting all the different patterns and components and refactoring the CSS and learning Sass all at the same time. I wrote a little bit about that on the blog, which was right about the time that I started noticing people, other people were doing this too, and it was really exciting for me.

Since then, pretty much every job I’ve had ever since, I’m always advocating and I’m, like, trying to convince everybody that you need a design system. I did it at Do, which was my first team that I joined at Salesforce. It was a small, like, startup that Salesforce used to own. It’s now, we like to say in San Francisco, sunsetted, which is a really pleasant way of saying they shut it down.

But when I was there, I was doing a lot of mobile design. I found that I couldn’t really do an online style guide for mobile in the same way I was doing for HTML because I don’t know how to code for mobile, so I was doing a lot of redlining. Yeah, these are very painful to make.

I did a little side project while I was working at Do where I actually took on the design responsibility for the website and brand for Sass because I’d got, like, so into Sass from when I worked at Engine Yard that I pretty much went all in on the community. For this one I did an online style guide. Because it was an open source website, I was really concerned about the style guide being up to date. If somebody was going to add a color, like a new variable, they’re probably not going to remember to go to the style guide and update it.

I was exploring with using Yaml to generate my Sass variables and all that. Then that kind of led me to where I am now, which is at Salesforce. I technically was at Salesforce already, but when I say at Salesforce, I mean like joining the core team. What brought me there was I saw this style guide, which came out like three or four years ago. It was for their Salesforce1 app.

I thought it was really pretty, and this was the type of work I’d been trying to convince some of the other companies that I worked at, and nobody would take up -- take me up on it. Nobody would join me on the effort. Nobody would use it. Nobody would adopt it.

When I saw that a big company like Salesforce was putting a style guide out, it’s like, well, hey. This sounds pretty much like a dream job, so I switched teams. And right at that time Do was sunsetted, so it was really good timing. The Lightening Design System is basically what has evolved from that Salesforce1 style guide.

But I’m going to pause for a moment to ask really quick, like, does anyone watch Game of Thrones?

Audience: Yeah!

Jina Anne: I love Game of Thrones, and there’s a metaphor that I really love to use internally that I’m going to talk about, and it’s about dragons. So I view the design system that I am working on right now, with an amazing team, like a dragon, and I’ll explain why.

If you watch this show, you know there was like this cute little, like, pretty dragon egg. And in the show, like, people basically collected these, and nobody really expected an actual dragon would come from these eggs. They were kind of considered like relics.

Then you have, like, when they’re hatched you have these really cute, little, cat-sized dragons, and they’re really adorable. And then they become monster size, and they basically burn everything down. That kind of sounds really negative, but I’ll explain further what I mean by that.

Let’s talk about the egg mode of design systems. Usually this is when a company is, like, really just starting out with their design system. The goal for this is usually to invest in having a more efficient team. Part of that process is gathering.

When I talk about gathering, I’m talking about, like, getting all the information that you need before you even get started. I really love this comic by XKCD where it says, “Situation: There are 14 competing standards. 14?! Ridiculous! We need one universal standard. Situation: There are now 15 competing standards.” Standards like this proliferate all the time in companies because there’s no actual, meaningful value or, like, vision sought out at the beginning.

Last year at Clarity, my design system conference, there was a talk given by Isaak Hayes and Donna Chan, who worked for AppDirect, and they talked about using basic user research practices before you begin your style guide. That way you have a more meaningful, useful style guide. One of the people from Adobe attended the conference, and they actually wrote a fantastic summary of that talk. These links will be shared later, so you can get them later.

But they did a really great breakdown of that process, and I’m sharing it because this process that they went through is really super similar to the way we did it at Salesforce. It basically involves identifying who are all your different users and builders and stakeholders, interviewing them, and then taking, like, bits of basically like things that you notice surface up a lot, then defining what your principles are, and then using that to define what your stories are going to be for your roadmap.

Principles, I think, are really important, and I think it’s really important that your principles are developed through the user research that you’re doing. When we defined our principles, we kind of did a similar process. We did our interviews, and we tried to identify what was important to us. Then we did the whole sticky note, categorizing, and moving things around, and then finally landed on four principles. The way we kind of do everything is we always stank rank our lists, and so these principles are stack ranked in order of importance.

The images you’re seeing on these slides are landmarks in San Francisco. Our intern designed these, and then we ended up hiring him because he’s awesome.

The first principle is clarity. It’s actually a total coincidence that my conference is named Clarity. I bought my domain, like, two years before we landed on these. But, yeah, so Clarity says that we want to eliminate ambiguity, enable people to see, understand, and act with confidence.

The second principle is efficiency. Streamline and optimize workflows, intelligently anticipate needs to help people work better, smarter, and faster.

Then consistency. Create familiarity and strengthen intuition by applying the same solution to the same problem. Now usually when people talk about design systems, consistency is sort of like the first thing people talk about. But for us, we felt that clarity and efficiency for our users were a lot more important.

Then our fourth principle is beauty. Demonstrate respect for people’s time and attention through thoughtful and elegant craftsmanship.

When you have your principles in place, this is basically how you can drive your design decisions if you’re in a design debate and you’re trying to figure out, you know, does this need to be the same just for consistency sake, or maybe we can change it in this one place because it’ll provide better clarity or better efficiency. When you’re making those decisions, if you have your priorities in order, then you can use that to determine the stack ranking.

Obviously an inventory is very important for any design system. Some people do this with a Google, like, Google Slides. Some people actually print out all their components, cut them up, and assemble them. But the idea is you do this with lots of different people. Not just the designers, but you want to get execs in there. You want to get developers. You want to get PMs. And so if you want to learn more, this article on A List Apart goes into pretty awesome detail of how to do that.

Let’s talk a little bit about incubating your design system. Nathan Curtis, a pretty well-known dude when it comes to design systems, he writes a lot about them. I loved this article that he wrote about team models, which is a very common question that I hear from companies, especially smaller companies, like, how should I form my team?

He basically defines three models that he’s seen. One being a kind of like what he calls solitary overlords. That’s obviously just in connotation of the way it sounds, like not the most ideal way to do it. He also talks about the centralized model where you have a centralized design team. Then he talks about the federated model where you have designers from multiple teams coming together and contributing to the design system.

As you do on medium, I wrote a follow-up post to that post of how we do it at Salesforce. It’s really just a merging of the second and third model where we have a centralized team as well as a federated team, and we all work together and pair together. There’s no, like, top down. It’s very, like, we feed into their product design through our system, and they feed back into the system through their product design research and designs.

I’m not going to say the name of this article, but there’s this article that we use a lot at work. It’s basically another way of coming to a design decision if you’re having disagreements. Cap Watkins basically proposed a way of, if you give us, on a scale of one to ten, a fruit--or whatever other F-word you want to use--then you kind of win out. You would use this when you’re unsure of which way to go. And so, basically, if somebody really cares a lot more about whatever the issue is, then they’re going to win out. But nobody should ever pick ten because that’s not being very honest. Nobody should ever be a ten.

Then I think it’s really important to think very lean through the way that you embark on this adventure. Smaller sprints, focused sprints are really important. Marcin Treder at UXPin has been writing these design sprint medium posts. He has like a whole series of them where he’ll focus on, like, a typography sprint or a color sprint. I think that’s really great. Just pick one area and then focus on that.

Now we’re ready to release what we have or, as I like to call it, hatching. When we were trying to sell this to our other colleagues and our engineers, the common thing that people would say was, like, “You know, let’s just focus on buttons. We’re just going to update all the buttons.”

It turns out that it’s not really quite as easy as it sounds. Buttons are really complicated. They have a lot of different states. Some of them are grouped. Some of them have, like, extra functionality. It’s not as simple of a component that you might think it is.

On top of that, if you’re in a large organization like I am, you’re going to get a lot of pushback from people because they just don’t want to change their workflow. I don’t know where this comic came from, but I always think about it any time we’re trying to propose a new process. People just don’t want to change their process, because they’re too busy, even though your process would really help them have a much quicker and easier time.

One thing that really helped us is we were able to get executive buy-in. Once the execs saw the value of what we were doing and a big part of that was just that our stuff kind of just looked better than what was in production, they basically mandated all the engineering teams would now have to adopt our stuff, and so that was super helpful. I highly recommend getting your execs onboard.

You might be wonderingly, well, like, how do you do that? I find it’s always best to just show them. Don’t tell them. If you tell them, they’re going to think about cost. They’re going to think about time. They’re going to think about all these different factors. They’re going to think about maybe priorities that are more important to them. But if you show them, they’ll see it, and they’ll understand that.

I have found this to be the case not just in my org, but a lot of the people I’ve talked to that are doing the same type of work in their org who have gotten exec buy-in. Basically it just kind of--I like to say--“went rogue” and just built it, showed it. It doesn’t even have to be a full fledged design system. Just a proof of concept. Once they see it, they’ll get it.

I also think it’s really helpful to open source it if you can because then you get a lot of community help and feedback too. In some cases you can’t. For example like my friend Mina who worked on the Hillary campaign wasn’t able to open source because there are a lot of people that would use that type of resource for nefarious purposes, which is unfortunate.

Then one thing that we didn’t quite consider right away, but looking back we wish we had, was really thinking about our marketing strategy. When we first started out with the design system, we weren’t going to be called Lightening. We were just going to be called the Salesforce Design System because that sounded like it had more longevity. Lightening is the name of the latest release of our UI, and we were concerned that Lightening would be a temporary thing.

But marketing won out in that battle, and everything was Lightening. And so if we had considered that before, we might have done a lot of things a little bit differently. Now there’s another big marketing push that’s coming out this year, and so you’ll notice a huge UI refresh change because it’s all aligning to our marketing strategy, but this time we’re ready for it because it’s happened to us before. Now we’re better prepared for it going forward.

Now your stuff gets a little big. People have noticed. People are using it. People are excited about it. People are talking about it. Everybody wants components three days ago, and they’re just now telling you today. This is when I think of the design system becoming a really big dragon that you can’t really quite control. Usually at this point in big companies, small companies, wherever you are, it’s all about trying to--

Sorry. This is actually the baby dragon. I got head of myself. This is where you’re trying to set yourself up to grow. This is where you’re aligning everybody. What I like to tell people that I talk to that get really super stressed out is, like, just breathe. This is okay. We’re all in this together.

Empowering designers: obviously a big goal for design systems. Initially when we set out to do this, we thought everybody was going to design in the browser because that’s what we did. That was not the case, and so we realized that we have to help our designers as well through the tools that they use, so design system UI kits. People can use these in Sketch, InVision, Figma, or whatever tool of their choice.

Then, in turn, empowering our developers, and I don’t mean just the developers working on the CSS framework, but I mean the actual, like, engineering team. We do a lot of things for tooling because we’re on, like, a four-month release cycle. So like when something goes out, it’s out for like three months. We have to really make sure everything is in place and everything is trusted and vetted. We do that through things like design tokens for visual design, linting our code.

We even made a Chrome extension for developers that will basically grade their -- like it’ll tell them what pieces are actually using our design system and which pieces that they’ve overridden. It gives them an F if they override our stuff. The whole goal is that they use this Chrome extension to kind of like clean up the old override code. Things like visual regression testing, we even have a component previewer that we use internally because we realize that building this website every time we’re updating a component was kind of a bit heavy-handed, so now we separated out the framework from our site, and we have just have component previewer where we can see our code.

The idea is to stay living. I think this is something you hear a lot with design systems - living design systems. This is all about just keeping it updated, actually maintaining it. The biggest way to do that is that it’s part of your process. It’s not something that you put on the backburner or wait until the end. It’s part of your entire process.

Okay, so now we’re at the big dragon part. This is the part about really realizing how much your system has evolved. Sometimes changes are going to arrive, and you have to do a lot of optimization.

There’s this scene in Game of Thrones where Daenerys says, “I can’t control them any more.” The response is like, “They’re dragons, Khaleesi. They can never be tamed.”

I would like to say that, in the case of design systems, that’s not really the case. You can train people and educate people on how to use it. You definitely want to educate people. We do this through so many different avenues. We have Trailhead, which is our kind of like if you’ve ever used Treehouse or Codeacademy. It’s basically our version of that, but specifically for the Salesforce ecosystem, so we can educate people there. We do brownbag workshops. We do just onsite visits where we can help people know how to use the system.

A big part of doing a design system, especially if you treat it like a product, is support. Here’s kind of where I’m going to talk about things that are a little bit real, and I think a lot of people don’t talk about this part of design systems. Support is huge. Support is like a beast.

There’s all sorts of things that we’re having thrown at us right now, like we have devs that will override old code or mash our code with other code. Then when they’re seeing a bug, they inspect it. They see one of our classes and they throw it at us. They’re like, “That’s your bug,” even thought they’re not using it the right way.

This is where we have to really educate how these components are supposed to be used. This was initially done through documentation and advisory board meetings, standards reviews, audits, Chatter, which is our internal sort of like discussion board that we use, Slack, et cetera. But we realized we could actually clear a lot of this stuff and automate it, so that’s why we’re doing our tooling like the Chrome extension. We also have been working on a taxonomy system, so we can actually tell certain CSS classes what it’s allowed to go on, the restrictions, whether it’s required. We have all this metadata now attached to all of our classes so that not only do we show that in our documentation, but we provide a lot of tooling, automation, and testing through that.

In design systems, I think a lot of people think you’re going to build it and then you’re just going to always be consistent and always follow it. That’s not really how it goes. You’re going to change your mind.

A pretty good example of this is even just our documentation. We’ve changed the layout of our site for our components so many times just based on different research methods that we’ve tried, people we’ve talked to, different feedback we get. We’ll add a feature. Then we remove the feature. We’ll move it to the top. Then we’ll put it in a modal. Then we’ll put it in the sidebar.

We change it a lot. We’re trying to stay pretty iterative and respond to the feedback that we’re getting from our users. But, yeah, you’re going to be changing your mind a lot.

Then you’re going to be changing your mind a lot again. Another example of this is name spacing. When we first started out, we just had simple classes like button or tabs or data table. Then we found out, because people were combining us with things like Bootstrap, Foundation, or whatever other framework, that they were getting clashes. Luckily this happened during our alpha, so we went back and name spaced all of our classes and, by the time it was released, everything was name spaced.

Then you’re going to change your mind again. Unfortunately, after a year and, gosh, I don't know how long it’s been out, we realized that we had to change our syntax entirely. We tried to be agnostic. We are used on many different platforms because we have a developer ecosystem where people are using us on all sorts of different stuff, and we were using BEM for our naming structure, which involves double dashes.

It turns out that our production compiler is XML based, which means our devs that we’re trying to comment out things were getting big, fat errors. We found a workaround that would work where they have to configure a setting and then they would be able to comment, but that puts overhead on our developers. And so what we decided to do was to actually deprecate the old classes and add the new classes, which unfortunately makes our CSS look a little bit big right now. But through your tooling, you can strip those out if you need to. Kind of a bummer, but hey, things happen.

Speaking of deprecation, it’s really important to have a really good deprecation strategy. I think initially when we were starting out -- who does the little comments with “to do,” “remove”? You never are going to go back and remove it. You’re going to get busy, so we opened sourced a Sass mix in that basically wraps the deprecated code. You pass in the version that you want it to deprecate in and then, once it hits that version, it no longer compiles. Then it’ll throw a warning in your console, so you know to go and clean it out.

Here’s where I’m going to suggest something that is actually the opposite of what we’re doing right now, but it’s something I really believe. I think silos are a bad idea for design systems. What I mean by that is splitting everything up.

Initially when we started out, we had this really awesome hybrid, cross-functional team of visual designers, interaction designers, front end developers, all these people working together. I thought it was great, and we moved fast. Unfortunately, we’ve grown a lot. We’ve become a big dragon, and so now we have a visual design team, we have a patterns and components design team, and we have a front end team.

A hybrid like me just is sort of like, where do I go? Oh, I guess I’m stuck on the front end team because they need code. So I don’t think it’s a good idea, and this is something that I do see big companies do all the time. When I was at Apple they did the exact same thing. I personally really believe that a good design systems team should be cross-functional and you should embrace your hybrids.

We went through the growth stages: egg, baby, big dragon. Basically what I’m trying to tell you is design systems are an investment. I think, like a lot of people, including myself, have given talks where they paint this really rosy picture, but it is work. It is definitely work, but I think, through good human guidance combined with internal tools, it’s definitely worth the investment and it’s worth the effort.

But I also want to remind that design principles are so much more important than design standards. It’s okay to break your rules. Sometimes you need to because it’ll align better to your principles depending on what your context or feature is.

You can totally be creative. I heard people always complaining about how design systems stifle creativity. They don’t. They just give you all the easy pieces, and then you can build it and do whatever you want. What I like to tell people that are doing design systems is, like, it’s okay to let go. It’s okay to break the rules sometimes. It’s okay to have what we like to call the special snowflakes where things are just going to be different.

If you want to get connected with a really awesome community of over 2,100 design systems folks, the Slack that I run is designsystems.herokuapp.com. It’ll automatically invite you. It’s a really awesome Slack, and I’ve learned so much from the community there. There are so many great people in there.

As Marc mentioned, I do have a design systems conference in November. There’s also a new design systems conference I’m excited about, which is in June, called Patterns Day. I’ll be speaking there.

Then there’s also meet-ups popping up. In San Francisco I started the San Francisco Design Systems Coalition. Then we give talks at different companies or those companies are the ones giving the talks. There’s always a New York chapter run by Diana Mounter from New York City.

There’s also a mailing list: designsystems.curated.co. Lots of relevant links.

Then obviously styleguides.io is the huge repository of links, podcasts, examples, articles, and so on.

You can also just tweet at me if you have any questions. My name is @jina.

Thanks.

Audience: [Applause]