The Product Design Process

Creating Your Design System

Paul Boag

Paul Boag

The Product Design Process

Check out a free preview of the full The Product Design Process course

The "Creating Your Design System" Lesson is part of the full, The Product Design Process course featured in this preview video. Here's what you'd learn in this lesson:

Paul discusses the process of creating a design system including setting a grid, typography, colors, and aesthetics. He emphasizes the importance of building out components and elements, but cautions against combining too many elements into a single component. He also discusses the usage of different elements, such as modals and drawers, and the importance of having rules for when to use each element.


Transcript from the "Creating Your Design System" Lesson

>> But let's talk about actually creating the design system and how I go about building it from a design point of view. I keep adding that because I know obviously it's slightly different from developer point of view. I started my styles, right? So yeah, I maybe mockup some pages to just get a feel of what I want the design to look like.

But once I've got past that bit and I'm ready to actually create the design system, the first thing I do is work on the styles. And the first thing I work on in the styles bit is I set a grid, right? So I take my design that I've got and I work out what the underlying grid is.

My advice with this based on my years of experience is to add more columns than you think you need when you create a grid. Cuz you see things like bootstrap and these various other frameworks and they all have 12 columns, it's everything's 12 columns East States, but oftentimes you need more than that.

So I take whatever you think you need and double it, [LAUGH] because you won't regret it later. So I tend to create a bit of a grid layout. And then I work through and I start setting the padding for my layout. And what I mean by that is so when you create your grid, you're gonna obviously have gutters between each of your columns, and you're gonna decide what those are.

But then within the components, you're gonna have padding and margin that goes in your components. So it's worth defining all of those as well. Now, when l work in Figma, I define all of those as variables. Which is a relatively new function within In Figma and it's really worth doing that because once they're defined as variables, if you suddenly decide you wanna give everything a bit more space, you can just up the variable in one place and it ripples through everywhere.

Also, that tends to be more in line with how you develop things as well. You don't tend to hard code values in, you'll set them as variables and then you can adjust them at least if you're doing it properly. So I tend to do that next. So I've got different paddings, I've got different values for margins and that kinda thing.

And don't forget of course that Steve will cover this more in his in-depth dive on Figma. Then I tend to look at typography and I go through and I set my styles for typography within Figma. Unfortunately, you can't have variables in typographic styles in Figma yet, which is a bit annoying, so I can't set my font sizes as variables, which annoys me, but anyway.

So the ones I mainly set straight away is I define all my five levels of headings. I tend to never use all of them, but I like them to be there anyway. I include variations for different weightings for each of those sizes, and then I add additional styling for things like underlines, strikethroughs, capital letters, that kinda thing.

So, we're including our headings, we're including our paragraphs, our block quotes, all of that kinda typographic stuff then gets created as styles. So you can see how really you're gonna need to mock up a couple of pages first before you've got something to work with cuz otherwise you've got no context for anything.

Then I tend to pay attention to colours. So I do this in a bit, but this might be a main thing. All right, so don't feel you have to carry this over. There are two ways of defining colors in Figma. You can define them as variables, or you can define them as styles, right?

And I actually use both. So what I do is I define my colors primarily as variables. So as you're seeing on the screen, you're seeing here all of the colors for one project there defined as variables. So there's primary 1, primary 2, primary 3, primary 4, and then secondary.

And they're all variables, right? So they're completely independent of any particular element. But then in my styles, I go in and define which of those variable colors I use for specific use cases. So for example, my borders, right, that I go around every but my boxes are going to be secondary color three, for example.

Now what that means is that later on, if I want to universally change a color across the whole site, I can change it at the variable level, okay? If I, however, just wanna change the border color everywhere across the whole site, I can change it at the style level.

Does that make sense? Cuz it's a bit of a mind bender, right? You don't have to do it like that, you could choose to pick just variables or pick style, but for me that tends to separating out, I wanna change the color universally from I wanna change the color as it is applied to a specific item like a border, tends to work quite well for me, right?

But whatever. And Stephen his workshop might suggest something totally different. That's the thing, there is no right or wrong answer with all of this stuff. So, also then, the other element with colors is if a component is put on a dark background compared to a white background, the colors have got to be different, right?

Now, fortunately, just this is adding another level of complexity. I do apologize, it's not my fault it's complicated, it's Figma's. They have introduced like this modes thing that you can add. So with each of your colors, when you set it as a variable, you can say, this is the color for light mode, and this is the color, the same color if it's put on a dark background, a dark mode, right?

So you can kind of see on this graphic, it's not very good I apologize. It's so flipping small, but you could have primary color one, right, so that's the first one in the list. And if it's on a light background, it has a dark version of that color and if it's on a dark background, it has a light version of that color.

So it's adapting based on the background it is and that will make life a lot easier once you got a load of components and you're dragging them and dropping them into columns. If that column has got a dark background you can just say this is a dark background and that's an option in Figma and Steve will teach you that.

But once it's in there it'll automatically adjust the colors appropriately, which will make your life a lot easier, otherwise your are constantly overriding colors. So be aware of that one as well. Right, the other thing I would look at is aesthetics, which basically boils down to two things.

Rounded corners, so I'll go into my variables and I'll set different size rounded corners I wanna use, right? Typically, these are big, medium, and small, right? So it might be two pixels for small, it might be five pixels for medium, and it might be ten pixels for big.

And then if I ever wanna change those in the future, I can just change it once, place, and it'll ripple through the whole design system. So that's worth doing. And then drop shadows is the other one where I set that as a style. I have different style drop shadows which you can set in your effects style.

So the styles in some ways are the most complicated bit of the whole thing. Cuz with these variables now and these modes and stuff like that is a bit of mindbender. So once you've got your style sorted out, now you can pay attention to your basic elements. Which basically boil down to form elements, links, dividers, buttons, iconography, tags, things like that.

So I go through and I style up all those different things, right? Every form element, every button, every link, every divider, all of those little micro elements we now style up, right? So you can see a load of them on the screen there. But don't forget your states, as I ranted about earlier.

So for each of those elements, we've now got a set of hover state and active state, a selected state, an expanded state, right? And we got to do that for buttons, we got to do it for links, we got to do it for form elements, we gotta do it for a, what was it?

What was the name of the equipment?
>> So we hide things.
>> So we hide things, yeah. So we really need to kind of go through every single one of those, making sure all the multiple states to that. So there's quite a lot of work in that stage building out all of those elements.

Once you've done all of that, and that's done, by the way those different states are done using components and you can switch between components. I was gonna get into all of that but I'm sure Steve will do a far better job about telling you how to build components well, so we'll leave him doing that.

But once you've done all of those elements, then you can build out your components and the components you need will be totally dependent on your project and what it is that you're doing. But I mean, here's just a random few that Kind of, I pulled off of a recent project I was working on, but there could be many, many more, depending on what it is that you're doing.

It can mess with your mind working on components. So, it's all about abstraction, right? And this is where as developers, those of you who are watching this who are developers, may well get pulled into a level of abstraction that you regret later, okay? So let me explain what I mean.

When you build a component, let's take, say, for example, a news listing component, right? You're gonna list news stories, right? So a news listing component probably consists of a thumbnail image, a heading, a description, a published date and an author. Sounds about right than it, that's the kind of thing you want when you're listing out a new story.

Great, that's wonderful, right? So we build a news component, well, hang on a minute, right? What about an events component? Look how much overlap there is. Image, heading, description, sort of a published date as a start date and time, and you've got an end date and time. Well, hang on a minute.

We can combine these together into a single event slash news component, right? And we can just make them, the author we can have as an optional one that turns on and off and the end date we can make as an optional one that turns on and off, right?

Makes a lot of sense that's a smaller code base to look after. You're you're sucking in your breath there and you're right, it looks really good on paper and it kind of makes sense in a lot of ways, but it comes back to bite you because you go, well, hang on a minute.

At a later date you wanna do something different with news, but you've now got so many conditions. So you've got different conditions going on for the news elements within the same component and the component becomes more and more complicated, right? But then, you can have the opposite problem as well when you end up creating a load of additional components that aren't really needed cuz they're so similar to other components.

So there is a happy medium somewhere in there, and I wish I could give you a set of rules that say do this and don't do that, but it's not that simple. But I would be very more careful of ending up combining everything together than having things separate.

I think it's better to have things separate than it is to have one component to rule them all, which is you can easily get into that kind of mentality if you go down the rabbit hole. So basically then it's all about just building out the components, building out the elements, building out your styles.

And Steve's tour of Figma and using Figma will teach you all of that kind of stuff, I am sure. But there are other elements to design systems that are a little bit more opaque and not so easy to think about, and this comes back to what you've been patiently waiting for me to talk about, which is modals and usage of different elements at different times.

And this is a really big thing cuz it's not just about having a component, okay, we've got a component. Equally critical is when you use that component and when you don't, and actually these are three great examples here, right? So we've got any three examples, we've got a model, we've got a drawer, and then we've got an expandable overlay thing, right?

And when I was working on this app and I was looking, they had these three components already, but it was random as to what you got, [LAUGH] right? You clicked on a button, you didn't know whether you were gonna get a drawer, you didn't know whether you were gonna get a model, you didn't know whether you were gonna get a popover or anything else.

It was just like, whatever the developer felt like at that particular moment is what you got. So having rules around the usage of your components is worth having. So, for example, we use draws when we wanna display additional information that adds to the information that they were previously viewing, right, without having to go off to an entirely different screen.

I'm not saying you do this, I'm just saying these are the kinds of rules we made. And then we use modals, where we want a user to confirm or act on something that's happened before they proceed, right? And we use a pop up overlay, which is the one on the left, when we want people to take a quick optional action that's up to them.

And our logic for that is a draw provides a lot of space. So you've got a lot of space to add a lot of content, a modal, you can't interact with anything behind the modal until you've taken the action that's in front of you. So that's why it's the right choice for things where you need to act on it.

While a pop up overlays for optional actions that you could go on, I don't wanna do that and carry on with what you were doing, right? That was our logic in that particular case. The logic doesn't matter, what matters is that there is logic in place that you know when you're gonna use one thing over another.

So thinking that through is really worthwhile as well. The other little kind of gotcha that sometimes happens with design systems is you can get so bogged down in the working on components and elements and this kind of stuff that you forget to step back, right? And every now and again create a page with these elements in rather than looking at them in isolation because sometimes it can go horribly wrong when you put them all on the same page.

The biggest thing is it ends up looking incredibly busy cuz there's just so much going on cuz you've put too much in each individual component, but you don't notice it until all the components are together. So make entire pages from them.

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