Ep. #17, The Rise of Design Systems

Brian Douglas: Welcome to another installment of JAMstack Radio. In the room to my immediate left is Kaelig.

Kaelig Deloumeau-Prigent: Hi, I'm Kaelig. I'm a French developer in San Francisco, and I work at Salesforce on the Lightning Design System.

Brian: Awesome. I didn't actually realize you were on that actual specific system, so I'll have questions for you. And then also in the room we've got Rafa, who's been here before. So Rafa, say hello.

Rafael Conde: Hi. I've been here before.

Brian: Yes, that is very correct. And then, finally, Craig, all the way in the corner.

Craig Wattrus: Hey. I'm Craig. I'm South African, and I work at Braintree on our developer experience team.

Brian: Cool. And obviously, I'm Brian. I'm American. Rafa is Portuguese.

Rafael: We're diverse.

Brian: I guess our engineer is, I guess, American. I don't know. I didn't ask him before we started. But I'm just going to make a really bad assumption and assume. But anyway, we didn't actually come in here to talk about our nationalities. We actually came in to talk about design, and specifically design systems.

So Kaelig, I was mentioning before we actually hit record, we actually had a conversation a few weeks ago, and you had mentioned what you did and we talked about design systems and your blog post that you actually wrote. Do you want to explain what your blog post is about and what design systems are?

Kaelig: Yeah. So

Design systems typically come once your company is at a point where they feel the pain of scaling design principles.

And a lot of company's have something like a CSS framework or style guide. But then you can take it a little bit further, and typically that's where design systems come into play. Yeah, so at Salesforce, we're a pretty big team working on this design system.

Brian: How big is your team?

Kaelig: So when I arrived, I think we were like five or six, a little bit more maybe, and then now we're more than 20, 25 people, depending on how you count and people who are 50% on the project. So part of that team is more engineering driven, not necessarily design driven, because we've got UI engineers who are more on the CSS train and then we have designers, graphic designers, and then we have a few engineers who facilitate the delivery of that design system. So that's the stuff I've been writing about.

Brian: Okay, very cool. And then, so Craig, you're at Braintree, which I originally asked you on to talk about how a designer works with a mostly developer-focused product. What is your role on the team and what do you do?

Craig: Sure. I'm a product designer, and my team works on PayPal's developer docs as well as Braintree's developer docs, so it's a large base of developer users and a lot of development tools that we're building internally that deal with developers.

Brian: And do you guys have a system in play of how to interact with your current state of your product?

Craig: A design system?

Brian: Yeah.

Craig: Sure. In PayPal, there's a much more set design system, because it's just a much bigger product with a lot more touch points, and Braintree is a little bit more free form, because we're more like a startup, which it's quite exciting to be able to work between a more set design system and a more free form design system. I'm dealing with almost the same developers working across both, and the differences between that.

Brian: Cool. And then, having a design system, I guess anybody can take this question, I know what a style guide does, but the design system, does it help when you have difference of opinions within the team? I know onboarding and having a style guide for code makes it much easier for people to come on board and write code a specific way. So is that what you guys are looking for with the Lightning?

Kaelig: So I feel like there's multiple definitions of style guide, and I want to clarify the one we're talking about right now is not a coding style guide, not like the Airbnb style guide for example, which you had in a previous episode.

Brian: Yeah, it was, episode number four? It was episode number three.

Kaelig: So coding style guides are different from UI style guides. So design systems are going to more be around design style guides.

Brian: Okay.

Kaelig: And you can include coding practices inside your design system, but it's not the main function of a design system.

Brian: Okay. And then, so the people putting together design systems, these are UI developers, or are these designers?

Kaelig: It really depends. Some companies have engineer-driven functions for the design system, and some people decide that it should be under marketing or under design. So it really depends on the company structure. I feel that the best is when engineers and designers come together to build a product that bridges the gap between both languages.

Brian: Yeah.

Craig: And if I could interject there, it's also if the marketing team also gets involved, because often there won't be designers or developers, but they're setting a lot of the style even with their agencies or whoever they're working with. And when they also are involved in this design system, then everything from the marketing site to your developer docs or your app are going to work together.

Brian: Yeah, and have that consistency.

Craig: Yeah.

Rafael: When do you guys think is the best or the right time in a company's life cycle to start working on a design system? I don't think every single startup company or product needs a design system, right? When is the right time to start working on that project?

Kaelig: I think there's different scales to a design system. Not everyone should aim to do a Lightning Design System from day one. I feel like you can start with super small abstractions around your color system, your typography, a few things like this. And then if need be, if your company grows, if you have lots of stakeholders and people start having inconsistencies in the user journey, then you can start growing your design system, or at least your initial layer of abstraction. Does that make sense?

Brian: Yeah. So it just seems like on an as needed basis, as you see some sort of inconsistencies, or you see consistency, you can then abstract that process. For example, when I first started at Netlify, which is the company I work at, I did a really easy CSS audit and saw we had like seven different colors of green on our homepage.

So I think something like that, we just don't know what hex code to put in one spot or what fonts are preferred on certain pages, it makes sense to come to a decision across the team to say that. And it sounds like design systems, it's a broad term for something that could be either small beginnings or very large like what Lightning looks like.

Rafael: How I see this is that you're talking about a style guide, and that might be the first thing that you build out in your design system. I wouldn't say at the point where you're worried about the color differences or things that you're looking for a design system. You're looking for a style guide, and a design system is really hard to build, in my experience, when you don't have enough use cases being solved, so if you just have a app with a few functions and you've got a website, there's not much of a system.

You're not solving a ton of problems yet, and

Once you're solving a ton of problems and you got a lot of different ways of solving those problems, that's when you want to really invest in a design system so that you're doing it consistently across all those things.

For example, at Salesforce, you'll have a big team working on this. At a startup, your designer is just going to make sure they have a style guide.

Brian: So Kaelig, go back to your blog post. The headline is Design Ops. So I don't know if you dropped that term in your explanation, but what's the difference of design ops and design systems, or is that you need ops to make the systems?

Kaelig: So the article actually is talking about design systems ops specifically, and then there's definitely been some talk around front end ops and design ops. So for example, Jon Gold's team at Airbnb is definitely design ops. So I wrote this article because I felt like people start thinking about delivery and how to measure that impact that engineers inside a design team can have.

So how do you judge the efficiency of those engineers inside of a bigger team, and what are their functions and how can they build better bridges towards production essentially? So that function is essentially trying to reduce the distance between the design and the customer. And in big companies, there's sometimes a really long distance in the middle of that process between ideation and what the users see, there's so many steps.

So what can be automated, and what gets in the way of the design getting shipped? So that's what those people are supposed to do. And then the design system, because it's supposed to be the single source of truth of all things design-led or design-related, I feel like that function can have a huge impact at a company.

Brian: Okay. So Craig, you mentioned there's a separation between Braintree and PayPal. So I guess, Braintree, internally, I guess we'll come off a little bit with the design system. Actually, I'm interested in how that parallel works. Do you guys never talk to the PayPal people, or is there a cross pollination ever happening?

Craig: There's a very big cross pollination for sure. My team works closely with people in PayPal. We also work with the UX lab. We work with the people who design the design system in PayPal. We work with the developers. We work with the product managers. And some Braintree product managers are PayPal product managers, so it's a very tight knit team that I'm on. So yeah, it's not a parallel effort, it's kind of very mingled in, but the ways we design things on each, on Braintree or PayPal, are different, and very different.

Brian: Okay. So I do have a general questions, since I have designers all in the room. And Rafa, you'll probably laugh when I ask this question, but the question is, should designers code?

Kaelig: Long debate. I feel like you should do whatever you like to do, to be honest.

Brian: What should you do, though?

Kaelig: Well, the thing is, if you're designing for a certain platform, I think you should understand the boundaries of that platform. It doesn't mean that you should be able to know how to build the whole app to be a good UX designer, but having one hand in the code, I feel like it helps.

Brian: Does it help with empathy?

Kaelig: Good question. What I like in my job is that

I get to create abstractions that empower designers to get closer to the code.

So for example, one thing I like to do is building environments, like prototyping environments, so that designers can get to code in the browser as quickly as possible, instead of seeing that as a huge blocker for them to get their ideas to the browser. So yeah, I feel like it's kind of the engineer's role to go towards designers so that the bar is lower and they can get to code more easily.

Rafael: I think it's a very empowering and valuable skill to have, especially if you're designing for digital media anyway, the Web or mobile. If you know how stuff is going to be built and how it works, it empowers you. I really think you are a better designer if you know exactly how your vision is going to be turned into reality, reality, quote on quote.

Brian: I guess you can just equate that to like if you are designing for fashion but you don't ever wear clothes. That's a really bad example.

Craig: I think you can understand the concepts behind code and the limitations of code and the ways of solving problems with code without actually being able to code, and I think I've seen, we code a lot, a lot of the designers on our team have computer science backgrounds, which is super useful in our case, but I have also seen really, really good designers who don't code and don't have an interest in it, but they can sit next to a developer or pair or with a developer perfectly fine.

And they can also grasp when they're doing a design the limitations of the browser and of those sorts of things when they do it. You definitely can't do it in a black box, but you don't have to know everything about it. Sure, knowing it opens up this massive array of tools and this new way of solving problems like an engineer, but to be a really, really good world class designer, you don't have to do it.

Rafael: I feel like now with the popularity of React, we've seen a lot of designers sharing the same language now with a bunch of developers, the definition of a component or something. We're talking about designers know what it means, and even, with Sketch, for example, has symbols and asset symbols so designers, maybe I'll speak for myself, but I started designing a lot in this component mentality.

So in tools like Abstract, which bringing Git to designers, so just the vocabulary of Git, what is a branch and what is a commit and what is a pull request? We bring in that basic knowledge and language to designers, which is, in my opinion, great for all this collaboration and communication between.

Craig: Do you think it's taken a step back, React, though, with making code friendly for designers?

A lot of designers I know who do code find React very hard to grasp as a actual coding concept.

The concept is great, as you say, for components and composing components, because they work very similarly to how Figma or Sketch would do that, but they're a very different mental model to a standard HTML page or a templating language like Handlebars.

Rafael: I think that the mental model, I think designers can understand it and a lot of them are embracing it, but now the bar of entry, like how accessible now it is to build an app in React as opposed to just simple HTML and CSS website, maybe now that's a bit harder to get into.

But I feel like React, nowadays if I had to teach React to a designer who never touched code or JavaScript is so hard. I don't know where to start. It's really hard. But, on the other hand, we have powerful user interfaces. On the Web, we are building apps. It's not just a website.

Brian: Kaelig actually kind of hinted, too, Airbnb's team, which has a React component tool that either creates Sketch files or reads Sketch files.

Kaelig: Creates it.

Brian: Creates it? Yeah, so very interesting and intriguing.

Rafael: That is bananas. That is jungle magic, so I don't completely understand it. But that's another thing. Now, if you take a design system and you were saying that's the source of truth for all design related work, but on the other hand, you have a Sketch file that you have to maintain, and then you have maybe a bunch of React components, so there's not one single source of truth, I guess, because you still have this separation.

Craig: Unless your React components are your source of truth.

Brian: Yeah.

Craig: That's true.

Brian: Which is interesting, because we, at Netlify, we had started about a year ago doing React Storybook, creating components so you can quickly design and get it into code, and then that way we have a source of truth for all our components. So if we need a forum or we need a credit card functionality somewhere, we know what it looks like. We literally just drop in components, and then we're most of the way there.

There's a lot of Redux that needs to happen, but at least, as a developer, I can just pull off a shelf of components already built and designed and approved by Rafa, and I'm good to go. So I'm curious. As far as tooling, are there other tools out there that create these design systems as far as, it's a source of truth, but are there things that help stand it up?

Craig: Figma Design is doing some really great things. I don't know if you guys have heard about it.

Brian: I've actually heard about it a lot in the last week, for some reason.

Craig: So they have a system called team shared libraries where you create this shared library for your team which consists of components, and they also update it. They don't use the words as git do, but you still go into your design style guide, your design system, you update a component and you publish it, and then when any file that has that component in it will actually, when you open it, it'll say, "Hey, there's updates to your components. "Do you want to update them?" And it'll give you diff, a visual diff, of what those changes are.

Brian: And these are design assets, not actual code, in Figma?

Craig: It's design assets.

Brian: Okay.

Craig: On PayPal or Braintree, our design system sits in code, and PayPal is in a repo that you can include as a package in your project, and that'll give you all of those components. There's a website where you can go see all those components. In Braintree, it sits mostly within our SASS, so slightly less defined for this, but if you go look at our SASS code and you look through that, you'll find the components there.

Rafael: There's some maintenance that has to be done, right?

Craig: Yes.

Rafael: Someone has to update the Sketch files or whatever. If a new hire comes in, decides to build a UI for something and he has a basic set of components and all this still in Sketch art, Figma or whatever, so there's still this back and forth. I know, at least at Shopify, they have a whole team and that's their job, to ensure consistency across teams and across everything, which is bananas. By the way, by the time this episode comes up, Sketch has a similar thing out there, like shared libraries.

Brian: Yeah, they are still working on it, yeah.

Rafael: Cool.

Brian: Yeah, listener, look that up. So you mentioned a really good point, bringing on new designers. I assume things like Lightning, and I know Lightning has been out for quite a few months now. I don't know if you've seen many design or UI people be onboarded after the point, but do you find it's an easier process to onboard someone, say, "Here, look at our source of truth. Let me know if you have any questions." So what does that process look like?

Kaelig: Yeah, it's been a huge improvement. Actually,

One new hire wrote a blog post about how easy it was to onboard on the design language because of the design system.

And so it was a huge reward. And we're really impressed, because the Lightning Design System is shipping HTML and CSS. Of course, we have a whole lot of design guidelines and best practices and, "How we talk to customers?".

But what our bread and butter is, well, it's components, essentially. And we have so many different stacks that the only way we can ship that is not React components. It's not Angular components. It's just pure HTML and CSS so that then any implementation, and it comes back to what we said before around you need people to update their implementations.

And yes, it's a cost we're ready to pay, but I'm really impressed when I see a designer who is very comfortable with Vue.js or Angular and builds a whole prototype, solving really, really complex problems and they don't have to learn React or learn our own Aura framework. They just plug HTML, CSS, into their habits, their way of coding and their way of tinkering in the browser, and they build amazing prototypes.

So that helped a lot. And then we now have a team who's in charge of keeping the Sketch files up to date. We're at the point where it's not really a big problem if the Sketch files are not completely up to date because in production it will get corrected anyway. The intent is really what's important for us.

Craig: That hits it on the head for me. Your Sketch files don't have to be 100% up to date unless you fundamentally change the way something works. The source of truth is that HTML and CSS that you can pull down.

And when you're pairing with developers to get your design through, you're going to learn about those things. The big thing is that you're solving the design problem, and

The design system should take care of it when it gets implemented and you missed something where you were using an outdated version of a style guide.

Brian: So, and I don't know if you guys have been around long enough in your companies or previous companies to answer this question, but what happens if you guys go to design 2.0 or design 3.0, the next wave of design? What happens to your design system? Do you fork it? what happens to your design?

Craig: Iteration.

Brian: Iteration?

Craig: Iteration is, I feel like, that's where it is.

Brian: Okay.

Craig: I don't know if you ever used Foursquare way back, but they just kept redesigning their app. It was totally new every few months, and we used to see that a lot with different apps and websites, whereas now we're seeing a lot of movement. Airbnb is a great example. If I go to an Airbnb today, it's fundamentally different to how it was a while back, but I can still see it's Airbnb. It feels new. They just keep iterating on it.

Kaelig: Well, they did a massive redesign, though, that was one of the best orchestrated redesigns I've ever seen, because all at once, they redesigned everything. All that stuff at once was like, wow.

Craig: To me, it felt like an iteration on the design, like a big iteration, but it didn't feel like this crazy new direction. Their new logo, all that stuff, it just felt like a natural progression. And that's, I think, a new design on that, it's like, whether you fork it or you, whatever you do, start from scratch, if it's got that same soul, you're going to feel it.

Rafael: There was a lot of drama on that new logo, by the way.

Brian: Yeah. So I guess iteration, we could talk about GitHub's black bar. To be honest, I hadn't even noticed that there's been any other changes. I just remember the black bar was the big thing that someone said something about.

Kaelig: Color changes for accessibility, as well, and there's reasons behind this change. And Diana Mounter actually has been speaking about it in her talk in New York about design systems at GitHub. Super interesting.

Brian: Yeah. She just gave a talk recently at the JAMstack conference, Active Ingredients. So she was actually just here on Thursday.

Kaelig: Nice.

Brian: Yeah. Honestly, I missed that talk. That was the only talk I missed, but I'm looking forward to the video coming out soon.

Rafael: Yeah, I was there. It was pretty good.

Brian: Cool. And I'm sorry, I interrupted you.

Kaelig: Oh, yeah. I know there was some drama about it, as well, about this color change. I think the reason is that they were not happy with the blending of all these grays at the top of the screen and they felt like for future iterations it made more sense to switch to black, which is what the enterprise edition of GitHub is actually using.

Craig: That was really hard after they did that to tell if I was on my personal GitHub or if I was on my enterprise GitHub.

Brian: Interesting. Design is everywhere. so, again, back to my original reason for doing this. I just keep seeing more and more people talk about design systems, and as a developer, I'm not really in tune with design. I remember the Airbnb thing. I remember the GitHub thing. I remember when Lightning came out. But I don't have my finger on the pulse of design.

Rafael: No one has.

Brian: No one has the pulse?

Rafael: There is no pulse.

Brian: So is it going to look like everybody is going to roll out their new version of Lightning, or is there going to be a design system that everybody flocks to because it solves most problems when it comes to operations of design and discovery?

Kaelig:

I don't see something like Bootstrap becoming the next design system for everyone.

Because there's so much more, from the band, from the voice and tone. There's so much you can put into a design system. You could even codify how chat bots should interact with customers inside a design system. Any interaction pattern, you could put that into a design system. So I don't think that there's going to be a one size fits all. So is anyone using React Storybook here?

Brian: Yeah, we are at Netlify.

Kaelig: Has there been some recent movement on the repo recently? Are the maintainers just dropping the ball or something like that?

Brian: Yeah, so I do know the history on that where the maintainer has had a life change and a career change which has caused them to work for an actual company as opposed to consulting. So open source wise, people have stepped up to take over, but it's still a bit in limbo. So there could be some big changes. It could just be pretty stagnant in moving forward. But there is a team around it that is now going to take ownership for it, but that's as far as I know.

Kaelig: So I see that kind of system as the closest thing to a ubiquitous way of building not necessarily design systems but at least big component libraries.

Brian: It seemed to have a lot of potential, but it got really stagnant really quickly.

Rafael: So there's this very interesting piece by David in Quora. So someone asked, "Why are so many product design teams building design systems these days?" And he had an interesting take. He said that with UI, now there's not a lot of innovation in that field. It feels like Bootstrap and user interface nowadays for mobile or for Web is pretty standard. We reached a level of maturity that you're not going to release a terrible UI.

It's easy to get the basics done. So he says that design system is where innovation can happen, in a way. It's the only way for you as a designer to be super innovative and try new things, and that's where we're going. Because it feels like, maybe I'm biased because where I work at in the town that I'm in right now, but it feels like designers are more and more interested in going the extra mile.

That's why designers are learning how to code, designers are learning React and all, because we want to go the extra mile because we want more innovation, because UI design is getting pretty stale at the moment.

Kaelig: Yeah. I think to come back to the target audience of this podcast, you can see the same thing with developers. When they're growing their career, just writing code for writing code is not necessarily the most exciting thing anymore, and so a lot of people start thinking about architecture.

And it feels like the same thing is happening, and design systems is kind of design architecture, I guess, where you think about the bigger picture. And pushing pixels is not necessarily what's making you feel good about your job and your impact, and so design systems can be one evolution of that.

Craig: I'd see it as like a double edged sword. This might be not the most popular opinion.

I think design systems cause complacency in design where we just solve something with the components that are available instead of rethinking how something should be solved.

But then on the other side, sometimes it can bring about incredible innovation. So I think it's just with each problem "Am I solving the user's problem for real, or am I just putting together some components because that's what I've got to do? "And really, maybe it's an irritation for me to reach out to my design system maintainers and get them to update their component or change their mind about how something should work, so I'm just going to use it. So I think it's just something to, while it is a great point of innovation, something to also keep in mind is to be careful.

Brian: Yeah, don't get stagnant.

Craig: Solve the real problem.

Brian: Yeah. Going to your point, code, I think, it's changed a lot in the last couple years. Like now with React solving the view problem. There's other view libraries, like Vue. But it's opened up other things like Redux, which has solved the data flow problem. And it's also opened up even more interesting things, like GraphQL, which is then solving the data problem one step more.

So I think we're moving forward as the Web changes, and I think, as you said, Rafa, we're moving design forward, as well, so no more simple UI with the hamburger menus. I think hamburger menus are kind of dying. I don't know.

Rafael: I think it's still everywhere. Sometimes they still work.

Brian: Iteration.

Craig: It's common sense that they're the devil now, I think.

Brian: Well, with that being said, I'll go to end the conversation there, and let's actually move to picks. So there are our JAM picks, things that you are jamming on, things that get your interest. It doesn't have to be design or developer related, though if you have them, please give them. But I will start the tone with my first pick, which is air conditioning.

I am a very big fan of air conditioning, especially these past couple days. I think coming into Heavybit's office is actually a breath of fresh air, literally, because they do have AC here. And I tend to go to Safeway on the weekends if it's hot.

Craig: Just hang out there?

Brian: Life hack, just walk around Safeway like it's the mall and just hang out with your friends. And if they have a Starbucks, it's even better.

Rafael: Living the good life.

Brian: Yeah, living the life, air conditioning. I also do want to pick the Spec Network, too. They are a really cool network that has podcasts, as well, just like the Heavybit podcast, and they have Rafa's podcast, which is Layout, and then Design Details, as well. And then Immutable is also another one of my favorites, as well. So definitely check it out. And Kaelig, did you have any picks for us?

Kaelig: Yes. I've got two picks related to design systems. So first pick is the Design Systems Slack channel, designsystems.herokuapp.com for registration.

There's more than 2,000 people in there who are super passionate about design systems. And so that was kicked off by Jina, who's one of my colleagues, and she's awesome, and she's also putting together a conference in November, I believe, called Clarity. And Clarity Conf was last year just amazing, one of the best if not the best conference I've ever been to with some really legendary speakers, such as Richard Danne, who built the NASA design system back in the '70s.

Brian: My joke is usually, whenever I'm teaching people how to code, I'm like, "Write the code. See the console error. We're not launching rockets. It's okay." In that case, if you're working at NASA, make sure it works.

Kaelig: Yeah, yeah, yeah. So that's my two picks.

Brian: Cool. Rafa?

Rafael: Mine has nothing to do with design.

Brian: No worries.

Rafael: I've been really into Mario Kart on the Switch. It's awesome. So I guess it's two picks, Switch and Mario Kart. They're great.

Brian: Cool. And Craig, did you have anything else you're jamming on?

Craig: Yeah, I've got one pick, and that would be, I mentioned it earlier, Figma Design. I have spent some time with their team and they're really moving really quickly in the design space. Their vector tool is absolutely amazing. Team libraries, I know Sketch is working on something similar, but right now, their team library is something quite unique. And yeah, I use it on my Windows computer at home, on my gaming machine, or at work on my Mac.

Brian: Yeah, it's web based?

Craig: Yeah, it's Web-based. They have apps for Windows and for Mac. It is a Web app wrapped in a but, Electron, yeah. But definitely changing the way we do work and pairing using it.

Brian: Cool. Well, thanks, Craig, and thanks everybody for your picks, and thanks for coming in to talk about design systems here on the JAMstack Radio. I definitely thought this was a really awesome conversation. It's actually sparked more interest for me to actually look into it.

Kaelig: That's cool.

Brian: Thanks again, guys.