Episode Transcript

Ethan:

Hi, this is a Responsive 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, well, I don’t think it’s possible for us to be more excited, because we are here with you today speaking with Mari Johannessen and Bethany Schwanke, who are here to tell us about IBM Carbon, IBM’s design system. Mari, Bethany, thank you so much for joining us.

Mari:

Thanks for having us. We’re really excited.

Bethany:

Yeah, thanks.

Ethan:

So, before we dive in, maybe you both could introduce yourselves, tell us a little bit about what you do, and maybe tell us a little bit about what IBM Carbon actually is.

Mari:

So, I’m a front-end developer at IBM Carbon, and I have been working with the design system since I started working at IBM about two years ago. I recently got promoted to be the dev lead, so it’s been really exciting. Yeah, we have a great team there; now we have four developers, two designers, and one UX designer and one researcher. So, we’re a great group of people working on building this design system.

Bethany:

And I’m Bethany Schwanke, I was the founding manager of IBM Carbon and worked with them through version seven of Carbon. It was probably the best experience so far in my life of working with a team on a design system and design language. And Carbon design system is a component-based design system that is, for all intents and purposes, geared for IBM Cloud as a platform, but we’ve open-sourced it in the past year so that everyone can use the code. We support the React framework with it, so it’s been able to reach a lot of an audience, but we’ve also supported other frameworks in the past with it, and have some developers and designers who contribute to the product in different frameworks that make it available for use in other areas.

Ethan:

Well, once again, that’s fantastic news. We’re really happy you’re here. Maybe you could tell us a little bit more about how Carbon got started. Specifically, I’d like to know why IBM decided that it needed to invest time and resources in creating a design system, and if there were any questions or concerns that might have come up from stakeholders about dealing with a design system at all.

Bethany:

That’s a great question. IBM Bluemix came out of an incubation project that IBM has been working on for a long time with IBM Design. I mean, it was one of the first major products to ship out of that IBM design collaboration. When it shipped, the designers that were originally on it—Anna Gonzales is on the Carbon design team, but she was one of the original UI designers—and they just had like a two-page PDF with our colors and some basic components and typography styles, and that’s what the platform ran on for a couple of years, basically. It went through a lot of UI evolutions, and it was dark UI… And then, at some point, we started this process of acquiring a different company called Softlayer and realized that we needed a light UI, and this was a really good point in time where I was able to get a team under me that really wanted to work on a design language and that had been working on componentized pieces of the UI for a little bit.

So, it wasn’t an easy sell for the team to actually get to focus on the design system, but what we did was we made a really good road map, and then every month we pitched it to our executives and told them—we were very accountable to our progress and how far we were getting, and we educated them on the benefits they were going to get out of a design system and how much this was going to accelerate work and processes as we went. I think by the third or fourth pitch, we finally got people going, “Okay, I know what you’re doing right now. That’s enough. Just go back and do the work.” And so we got to be autonomous for about a year as we were building, and we had a first release that released themes. And it wasn’t all that stable, we hadn’t gotten things really under control yet, but they were able to see how the theming was able to shift us from dark UI to light UI really easily, or more easily than before. So, that bought us a little bit of time to get to a really stable release about eight months from the beginning of the project.

At that point, we got a lot of buy-in from a lot of teams, because all of a sudden they were able to say, “This page would have taken us three days to design and create in the old system, but with your design kit and with your components, we could sit down with our front-end developers and get this prototyped and done in a couple of hours.” And so at that point we just started collecting really good feedback and making sure that our upline got to see that feedback and got to see how much we were affecting the business and impacting the time and the money on that line. We were just very cognizant of getting that buy-in at all times.

Karen:

That’s a great answer. I would be interested in hearing a little bit about how thinking about a design system in the context of an organization as large as IBM might expand beyond what we hear on the Responsive Web Design Podcast and what many of the people in the web design and development industry think of as a design system. So, I see a lot of movement in this space led by designers and developers for trying to systematize standards on the web. When you’re thinking about something in IBM, is this something that expands beyond just the web touchpoint and might encompass apps or other non-web platforms?

Bethany:

I don’t know if we really want to talk about this yet, but there is a dream, an overarching idea that this will be an all-encompassing design system for IBM, and at that point it will evolve past Carbon and be at a larger level. But that’s still in the strategy.

Mari:

Yeah, and we’ve been starting—we actually have that on our plan for the rest of the year, is to collect more and more app designs from different teams around IBM; get screens, get components. I don’t think we, as Carbon, are going to build out those components ourselves, but we want to surface that on our design system so that people can come and get inspiration and see how other people are doing that, for the time being. And then hopefully in the future we can start creating more and more app design assets for different teams to use.

Bethany:

Yeah, you can see that work happening already in our theming site, where TJ and Mari built this really cool little sandbox that you can play in on the theming site—with Anna Gonzales—so that you can change the colorway that you’re using, or you can play with the rounded corners on buttons, just to nudge the theme around a little bit so that you could make a different brand theme. That’s one thing that we’ve put out there so that teams can start preparing for being included in the system.

Ethan:

Could you talk a little bit more about the general governance and maintenance of the design system? Mari, I think you mentioned it a little bit in terms of that give and take between the Carbon team and the different audience groups that might actually be working with the design system. When they might see a gap in the design system that might not necessarily meet a product need for them, how does that sort of bubble its way back up to you, and how do you sort of manage that from a design standpoint?

Mari:

Yeah, so we have a couple different things that we do to make sure that we have an ongoing conversation with all the different teams that we are serving. So, one of the things that had been really helpful that we do—we have bi-weekly component check-ins, is what we call it, where we have a developer and a designer from Carbon made up with their “ambassador team,” is the word we chose to name it. So, we meet up with them for half an hour, and first the Carbon members explain what we’re working on, what we’re seeing in the future that we’re going to work on, what our sprint planning contains. And then the other team has the rest of the time to talk about their needs, and if they have any questions, if they’re confused about any of our components, or if it’s possible to modify components to fit their needs, and kind of working closely with each team that way.

And we also recently introduced Carbon Sessions, which is more like an office hours thing. So, that’s every other week as well, where we set up an hour where any team from around the world can sign up for a slot to ask any questions, or just give feedback, or explain what they’re doing that they think could be helpful for Carbon to include. We also do bi-weekly demo days, and that’s for the whole IBM Cloud platform, where each team has about ten minutes to go through what they’re working on in the past two weeks. It can be anything from a new design or new back-end feature that they’re adding… And that’s really helpful because then we can see what other teams are doing and identify patterns that we should add in, and it also gives us ten minutes to kind of quickly reach all the different teams and say, “Hey, we added this new feature,” or, “Tables are coming out in a couple of weeks,” and kind of get everyone on the same page, which has been really useful.

Bethany:

I think the really important thing was that we set up the design system, from the very beginning, to be a collaborative resource for product teams. When we started, we were very open to the product teams that were working on the platform and said, “Look, this is for you, we’re in service to you; this design system is going to serve you and it’s supposed to make your lives easier and not harder. We don’t want to restrict your creativity any more than we have to, so bring us your patterns.” It started off that way, and so I think that people gained trust with us at that point, and realized that we weren’t going to lead them into a style that they didn’t agree with, or take their decision-making away from their product team. We just wanted to help them get to where they needed to go with a platform that fit the patterns that we were using. So, I think the relationship that we developed from the very beginning went a long way to helping the system grow.

Karen:

Can you expand on that a little bit, and talk about how you worked with the people who were going to be using this design system to explain the purpose or the function of the various components, and maybe even to identify how those components would be named or described in the system? Alla Kholmatova has a fantastic new book out called Design Systems, and I think one of the points that she really drives home is that the design system only works if it works for the people who are using it, and that the definition of what those components do and why you use them and how you label them, what you call them, is probably one of the most important things in the design system. So, how did you make that work?

Bethany:

Yeah, so at the very beginning of the design system, we pulled together the product team visuals and UX designers—there were probably seven teams at that point. We were growing very quickly; the Cloud platform itself went from a team of like seven designers to five teams, so there were about eighty at the end. So, we pulled everybody into one room and collected all the patterns, we did an audit across the platform, we got them to debate what was working for them and what wasn’t, and to identify the needs that we needed to meet as a base layer. Then we talked through the naming then, at the base level. Now when we have a discussion and we’re like, “Well, is it a slider or is it a progression? What are we going to use to talk about this?” we’ll go back to the product teams and ask them how they communicate with each other and how they talk to their developers about those items, and that’s the naming convention that will come back for us.

We’re also really big on documentation. The UX designer and the visual designer get together and document the usage for the components as we put them out, down to the accessibility requirements, and then our front-end developers are really good about documenting how to use and upgrade the components that they have. The CSS naming conventions were also agreed upon at the very beginning.

Mari:

That was definitely a work in progress. We went back and kind of went back on our words a lot, and we had several meetings where we talked about small details, like should we use the BEM notation, and should we use SIT with the object… It’s like a customized BEM syntax that we used in the beginning. And then after we used that for a few months, we realized that it wasn’t working for our product team, so we kind of did a huge refactor, where we went to straight up BEM convention, and it’s been working much better.

At the same time of wanting to make sure that all the visual designers are on board, we also have a very close conversation with our engineering teams, which has been really helpful and I really recommend people doing that from the very beginning, because they are the people who are actually building out your product and you want to make sure that the thing that you’re doing is making sense for them, as well. So, when it comes to when we’re using like CSS variables, when we’re naming them, when we give them the freedom to kind of toggle on and off features—stuff like that, we’ve been trying to make it as customizable as possible for both the other front-end developers on IBM and the engineering teams.

Bethany:

Yeah, and a lot of the design team is co-located here in Austin, but a lot of the engineering teams aren’t. But we have three very active Slack channels that people can communicate with us through, as well as email and all the meetings that we’ve talked about previously. But those Slack channels have been worth gold, because everybody feels like they can communicate with us that way and ask the hard questions, and they know that we’re going to come back to them with an answer. It might be, “We don’t know yet and we’ll get back to you in a week,” but there’s always an answer.

Ethan:

That’s really great. One thing I think we’ve been circling around a little bit is managing versions of the design system—I think you mentioned that Mari might have joined around version seven. And I know that’s something that larger organizations working with a design system, when it gets published out to different product teams, somebody might be on version four, somebody might be on the latest version. How do you actually work with design teams to communicate that there’s an upgrade available to them? Are they able to cherry-pick different modules from different versions of the system? I’m just kind of curious how that process works.

Mari:

That’s a great question, because I remember when I first began working on—well, back in the day we called it just Bluemix Components, which was just a GitHub repo that had a folder for each component, and then we distributed it to different teams using the MPM internal packaging, so it wasn’t public at the time. And it was just me and a couple of other developers working on it, and I remember we would push out new versions almost every day that were very breaking. And we made some people a little bit upset when we started doing that more and more, so we figured out that we can’t keep breaking people, we need to have a good plan on how people are using this and letting them know about upcoming versions, and what they should do to update.

So, we officially started with deciding on having two breaking changes a year. That started with version six, and now we’re on version eight—that’s about a month ago that we released version eight, which was our second breaking change release this year. That has been really helpful, because then we have six months to prepare teams for what’s to come. We give them a road map; people can join in and say what they hope will be in the next release. We write migration guides for each component, so they know exactly what to update if it’s class names or if it’s any HTML changes, or whatever it may be. Then we use semantic release for the rest of the releases throughout the year. So, we have the minor release and then we have a patch release. That can happen multiple times throughout the day, where people can get an update to their version. It can be version 8.1.2, which means that we’ve released a new feature but it’s not breaking, and we fixed this bug but it’s not breaking, you’re safe to use it. A lot of teams are still on version six or version seven. So,it’s not expected that they have to upgrade immediately as soon as we give a new release, but we definitely recommend that people do that as soon as possible, because as a general rule we have that we support the new release and the previous release, but that’s as far back as we go.

Bethany:

To add on to what Mari said, we’ve become super disciplined about making those releases, even the minor ones, as loud as possible. We try to broadcast them in all our Slack channels, we yell it from the rooftops just to let people know that things are changing. That’s part of one of our guidelines of transparency, that we want people to know exactly what we’re doing at all times and have them know that we’re available and we’re watching our Git issues and our design issues that are coming through from the community. But it’s also just because we need them to know that things are improving and evolving, and that they need to stay in the loop with us. So, it works both ways, just the conversations around things are continuing conversation and not just a note that they get in their email once a month.

Mari:

And we also try to keep the website very up to date, so you can always go there and see what the latest release is, and we have a component status page where it tells you what version the component was released, if it has been updated, if it’s being deprecated. So, especially the whole deprecating components or deprecating features, we make sure that people have at least a year to adopt that change.

Ethan:

One of you mentioned earlier that accessibility is something that’s baked into the design system. I’d love to hear a little bit more about how you design for that, and maybe additionally if performance and page speed is something that’s under the purview of the design system. I’d love to hear a little bit more about either or both of those topics.

Bethany:

[laughs] I’m going to tell an anecdotal story about Mari real fast, and then she can answer the question more thoroughly. I feel like we’ve been really responsible to accessibility, and contrast, and typography, and basic tabbing order and things like that. But the night that we released public, we got a response on Twitter that said, “You say you’re accessible, but I couldn’t do this through a screen-reader.” And so Mari ended up staying up the whole night and redoing the site on her own, just to fix that, because she felt so responsible for that problem, that she fixed it. But yeah, it’s one of those things that’s near and dear to their heart at IBM, but it’s also just something that we hold ourselves accountable to.

Mari:

Yeah, definitely. Luckily we have a bunch of tools that we can use to make sure that our components are accessible. And we all went to this conference in Chicago last year, An Event Apart, where they had some talks that really touched me a lot—very personal talks about how everyone should be able to use the internet. Like, you can think that, “IBM Bluemix, it’s a very dev-heavy platform.” But it should always be available for anyone. So, that’s something that we highly pride ourselves on, being as accessible as we can be.

When it comes to performance, that’s something we definitely think a lot about. So, that’s something we’re pushing for next year, for our version nine release, is that we’re going to go through each component and we’re going to analyze them, run them through speed tests to figure out of there’s anything we can do to get rid of bloat or make it faster in any way, finessing the React version specifically, because that’s where a lot of things can be done to make it even more performant. We already have some practices implemented to make sure that it’s very performant, like we use the CSS importOnce module to make sure that if someone uses our whole repo, they’re not going to get a duplicate of all the CSS files in our repo, they’re only going to get what they need to make sure that their file size is as small as possible. When we went from version six to seven, we reduced our file size I think by sixty percent, I want to say. So, that was also something we wanted to focus on, dry the code as much as possible and getting rid of as much bloat as possible.

Karen:

Let me ask a little bit about how you measure the success of this design system, or the usage of this design system. What kind of data or analytics or other measures do you have in place to know if this is working for people?

Mari:

We use a bunch of different metrics to figure this out. We actually made our own little dashboard that we used to kind of follow some numbers. So, we look at, of course, our website views to see how many people are actually on the website and not bouncing off, and what pages people are going to, and what components they were checking out on the website, how many people click on the “download design kit,” or are going to the GitHub repo. We also track our MPM installs, so we see how many people have installed our Carbon components package and our Carbon components React package.

Bethany:

Yeah, I think basically just the visibility in the platform itself. We go through and do a quarterly audit of all the teams that are using the components; whether they’re using them as we ship them or they’re modifying them, we look at that. We look at how many business units are taking advantage of the library, and we report all that to our executives every quarter so that they know how progress across the platform is going. That’s one of the big things that I talk about now, is that the definition of success really has to be shared across the team, and you have to know that the success of the platform is usable and that it’s in use, and we’re not going forward to something intangible, like having the best designed or the cleanest code—although those are all great things to have. The definition of success for us is seeing the fruit of our efforts in the products.

Ethan:

Mari, Bethany, this has been a fascinating chat. I can’t thank you enough for coming on the show. But before we let you go, I would love to hear if you happen to have any advice for our listeners. If someone’s out there listening to this podcast or reading through the transcript and they’re trying to wrestle with their organization’s design system needs, do you have any advice you might like to share with them?

Mari:

I think my biggest advice and one of the reasons why Carbon has been a very successful design system is the fact that our team is very—we work across disciplines a lot, so we don’t separate the developers and the designers in two different groups. We all work together. Even from the beginning of the birth of a new component, we make sure that a developer is always involved in the process, and start working on it before the component is completely finished, because that will just make sure that you get a very accessible and user-friendly component to use.

Bethany:

I think my advice to people is that the messaging around the system is very important from the beginning. I would just recommend that you get as many designers and developers on board as you possibly can within the teams that you’re working to serve, and make sure that they know that that relationship is collaborative and that you’re working in service to them. And then just work to keep that transparency and that trust at all times, because the design system can succeed or fail based on how the community reacts to it and responds to it. If it’s not meeting their needs, then it’s not meeting your needs. I also think a lot of people think that once they get the basic design system done that you go into maintenance mode and it’s not fun anymore, it’s not innovative anymore. But this team has really shown me that there’s side projects and offshoots that they’ve developed even in their own time to make the system a lot more robust and to make a lot more tools for the community to use to take advantage of the design system and understand the design system more. So, I’d explore all those spider areas outside of the design system, as well.

Karen:

Well, I just have to thank you both for taking the time to come on our little show here today. This is a really interesting story. I always love hearing examples of how design systems work in very large-scale environments, and it sounds like you’ve really pulled this one off. So, thank you.

Bethany:

Thank you guys. This was so nice to get to meet you.

Mari:

Yeah, thank you for having us.

Karen:

Thanks to everyone for listening to this episode of a responsive web design podcast.

If your company wants to go responsive but you need help getting started, we offer a two-day onsite workshop to help you make it happen. We also offer these workshops to the public, so please go to responsivewebdesign.com and see when we’ll be in a city near you.

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 for listening, and we’ll be back next week.