Design Systems with Storybook, v2

Example Design Systems

Steve Kinney

Steve Kinney

Design Systems with Storybook, v2

Check out a free preview of the full Design Systems with Storybook, v2 course

The "Example Design Systems" Lesson is part of the full, Design Systems with Storybook, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve shares some examples of design systems from Microsoft, IBM, Twilio, and GitHub. Using a prop to set the variant of a component is a common practice. This prop might be "variant," "kind," or "appearance." The name used in your design system should be consistent across all components.


Transcript from the "Example Design Systems" Lesson

>> So we have a button, we have a story for that button, but I wouldn't go as far to say that we have even the inklings of a design system. We have verified that HTML works at this point. And so now we wanna think about what does the styling of a button look.

And this is where we get a little bit into the philosophy of design systems as well. Which is, I think the designers at my company spend a lot of times when they think about the design system, thinking about the design language and the visual consistency and stuff along those lines, right?

I am lucky enough to have a design team these days, right in always. And so it means that I don't necessarily have to think about these things as much. I have to think about the one, how do we actually implement that? And then two, again, in the same way that designers are thinking about the visual language for our users, I as the leader of the engineering team, think about what is the maintainable code base here, right?

We have done a lot of back and forth and a lot of time of rethinking what are our standards and rules for components, right? What are our best practices? When you grab a component, even in our internal design system, any given person should basically be able to guess how it works, and have a good sense.

You don't need various different props for the menu button that has the drop-down from the regular button. They shouldn't look different visually, that's what design cares about and your API's shouldn't be different for anyone in the engineering side. We deal with it in a very small level and little startup, right, with a seven person engineering team and a four person design team.

But at a company like Twilio, where not only did you have Twilio, right, but you had all of his acquisitions along the way too, right? And so I worked at SendGrid, which Twilio acquired, they later acquired segment, so on and so forth. So you didn't have one design language, you had many design languages, but one design system, right?

And then you could pass a theme to it, right? I definitely will make references to Twilio's paste, one point because I worked very closely with that team for years and years. And then we'll also talk about the one that I work on today. But there are lots of different ways that various different design systems handle, what are the different types of buttons as we saw?

So one of the things I did for us on the course website is I looked at the big ones, the kinda very popular ones. So Microsoft's Fluent design system, which if you use Visual Studio Code, you've seen, right, [LAUGH]. That's what's in there. Atlassian's design system, if you've used Jira, you've seen that one.

IBM's Carbon design system, which I don't use a lot of IBM products, but it is a very built out and very kind of robust design system. And one thing that I will point out if we kinda go into these design systems that you will see is, this is IBM's design system.

What's it using? What, does it look familiar to us, right? If I go into Microsoft's design system, what's this one using? Right, the reason I linked all these is cuz when in doubt, if you need inspiration of how to structure some stuff, just steal the ideas, right? If I go into Twilio paste design system, they have a site but this is just a themed storybook as well.

And so storybook is effectively the lingua franca, you can get some ideas of how to handle stuff as well. But there's lots of different ways of thinking about these buttons, and lots of different props. So you can look at, Microsoft Fluent has an appearance prop for your primary or secondary button.

Atlassian uses appearance, IBM uses a kind property, but you can see this primary, secondary, danger, ghost, tertiary, different flavors of that as well. GitHub uses variant, which is, unless somebody counter argues that we should use appearance, well, I can do it. I'll deviate from the script. But variant is definitely the most popular.

Twilio's paste uses variant, shopify's Polaris system uses variant, GitLabs pajamas. Side quest is your design system needs a cool name by the way. Ours is called Holocene, I forgot the reason for that. Adobe Spectrum, so variant is the most popular one for these primary, secondary, dangerous, ghost buttons, right?

And so that's probably what we're gonna stick with, right? And so we're gonna implement this idea, we're gonna start with a CSS module that kinda just has some pre-written CSS. Later on we're gonna talk about strategies for kind of taking what would be called design tokens on the design level of a design system.

Like what color is a primary button, what is the color spectrum that we use in this design system? Because that is both important for the designers to have a consistent visual design language, and it is also incredibly important for you when you refactor, or for you when your designers change the visual design language, right?

And there's lots of cases where that happens. For when I worked at Twilio, their brand color is red, right? And so like most SaaS companies didn't have a lot of designers early on, right? And so they thought their primary buttons should be red.
>> [LAUGH]
>> They're giggling already, says what the problem is here.

Red means things, red means dangerous, right? And so then there was this big, this is when we're still kind of, in the initial kind of phases of implementing pace. Okay, so then how do you across many, many, many, many, many microfront ends change all the buttons to red without a design system.

Their code wasn't structured that way originally, right? It is now, right, but originally it wasn't, right? And so how do we also, when we begin our design system, think about all of the things that could happen, right? It could be everything from you start out with a red button, right, which we were all smart enough to giggle about, right?

But there's also things like, your brand color's blue, and then they announced the rebranding and now your brand color is a more different blue, right? And what we wanna do is think about as we implemented a design system, how to defensively structure our code, so that we have the ability to lie to our bosses and say that we'll take weeks and then do it in 10 minutes and then go stare at the sun or something.

>> [LAUGH]
>> Cool, so we are gonna say the variant and we're gonna start out with the CSS module and then we'll figure out how to refactor that in a little bit. So like any of these, and if you don't like variant, and there's reasons not to like variant that we will discover later.

If you wanna make a kind appearance, that'll work as well, but these are the decisions that you need to make as a team, because you know it's the only wrong answer. Different components using different props. So whatever makes you happy is if you're like, Steve use variant because of a decision he made, because most of you use variant early on, but I hate that, use appearance, I don't care.

I'm not gonna say you have to use variant, variant is not meaningful. There are lots of different options. A different option is to kind of do this where you kind of, this is really a bullying for primary or secondary. I love this aesthetically and I insist on this in the first design system I tried to build in 2017.

I personally ended up regretting it, because one, you deal with this use case, which TypeScript can save you from, right? Absolutely, but then also trying to pass booleans around in code if you want to be kind of, if you do you wanna use the spread operator and stuff like that, like actually having strings and unions is just, I love the way this looks aesthetically.

But I will tell you as somebody who has built out an entire design system and SendGrid for this, that I lived to regret it, right? I looked at a lot of things and the first design system that I built, is a story that I'll tell you some other time.

So we're gonna go with the variant one and we're gonna go ahead and just kind of implement that. And this will involve a little bit of TypeScript, a little bit of storybook, and then a little bit of CSS modules, and we'll kind of refactor some of that as we go along.

In my design system, I'm gonna say that I've got three primary ones. We also have what's called a ghost button, and you might have seen that in some of the other design systems that we scrolled through. A ghost button is basically a button that doesn't look like a button, right?

Later on in this workshop, we'll also deal with the fact of the one of the most insidious things in web development, which is, we all know there's two real buttons, there's buttons, and there's links that look like buttons. Right, and ideally we'd like to keep a consistent design language across both of those.

So we'll look at a strategy for dealing with that. But we're gonna be hand wavy over that for a hot minute and get to it later.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now