The Product Design Process

Building a Design System

Paul Boag

Paul Boag

The Product Design Process

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

The "Building a 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 importance of design systems and their benefits in creating consistent and high-quality interactions. He explains that a design system is a set of guidelines, standards, and components that unify design and development efforts. The lesson covers the basic building blocks of a design system, including styles (typography, color, layout), elements (buttons, forms), and components (modals, carousels, menus).


Transcript from the "Building a Design System" Lesson

>> Design systems, I mean, they're brilliant anyway. They're useful to have. If you're working on any project for any length of time, having a design system is definitely worth it. But if you are working on a product, an app, whether you have a web app or such, whatever you wanna call it, having a design system I would argue is almost essential to enabling you to produce consistent high quality interactions, but also just to making your life easier.

So what is a design system? Why do we care? What goes into them? Well, basically, a design system is to set a guideline, standards, and components that unify your design and development efforts across the organization. So it brings together design and development. I see it as a kind of blueprint for design and developments, collaboration.

It's a shared point of interaction with them that can streamline building of digital projects products significantly. It's really worth the investment. So why do I consider a design system so important and why should you create one? Well, consistency is a huge part of it. Ensuring that your design is uniform, the functionality behaves in the same way, just enhances the user experience.

And to be honest Brandon, identity as well. I always think about the BBC when I think of this cuz they have something called the global experience language, right? Which is their design system. And the BBC is a fascinating organization because it's trying to appeal to such a broad range of people, right?

And so the thought of having one design system that kind of underpins all of it feels a bit counterintuitive in some ways because it's like, one minute you're on a website aimed at toddlers, right? And the next minute you're on the Radio 4 website, which is aimed at old people.

And then you're on the BBC Sports site, which is aimed at rugby people or whatever else. And so there are all these different audiences. Yet you could easily be moving between these sites. So as a parent, you might be going on to CBBs, right? And then be BBC News and then radio two, whatever.

So it's like they've all got to have their own visual identity. Yeah, if they work consistently that's gonna make my life a lot easier as a user moving between the sites. And so they've done this really clever thing where all of the functionality is totally consistent, right? A carousel looks is a carousel works in the same way, same layout, same everything on every site, but it's styled with color typography, rounded corners that kind of stuff differently for the different sites.

So it creates consistency without uniformity, without forcing the same brand identity on everything. So it's very valuable from that point of view. Then there's efficiency and speed. Really, this is big as well, because this will seriously, if you get this right, you'll be able to turn around prototype super quick.

And then those prototypes will be able to go into production and turned into working code much much quicker. Because there'll be a whole level of kind of code that just doesn't need recreating the HTML, the CSS, the JavaScript, maybe even some of the database site connection stuff that's going on won't need coding.

Once you've done one, I dont't know, news component that pulls back news stories, you've done them all, basically. It just makes the whole process so much easier. It also encourages collaboration. It improves teamwork, creating a shared language and a shared set of resources between development and design, which can be a bit of a fractious relationship sometimes.

So totally worth doing from that point of view ensures quality as well cuz each of those components, when you drop in that component, you know that that component has been designed once properly with best practice in terms of user experience. In terms of maybe accessibility, all of those kinds of things are baked into it, responsiveness is baked into it.

And it obviously has a cost reduction. You cut your cost by reducing the need to rework or duplicate effort, freeing resources for innovation rather than just reinventing the wheel the whole time. Flipping brilliant, I love designing systems, right? So if any of you actually got to build a design system before?

No, yeah, it's frustrating. You've done some with prototyping, you've done a little bit?
>> We're trying.
>> You're trying at the minute done a little bit, right? Okay, so what am trying to do is share with you the kinda basic principles more from the design side. I'm not gonna pretend I understand the code side, all right?

I briefly touch on that later, but I do wanna primarily look at it from a design point of view. Let's talk about the basic building blocks that go into a design system. So you've decided you wanna build a design system, where do you begin? Now, first of all, I will say that Steve that I mentioned earlier, it has created a second course on design systems that will go into a lot more of the practicalities of doing this.

And I'm gonna look kind of holistically at the top level of it and he goes into a lot more details. So I'd recommend checking that one out. As another guy called Ben, who has got a course on enterprise design system management, which I suspect looks at it more from the developers side of things and the management of design systems.

You might want to check that one out as well. So my role here is to kind of look top level, holistically at it, if that sounds pretentious enough, right? So let's look at the basic building blocks that go into a design system. So there are fundamentally three, right?

There are styles, right? By the way, I'm gonna use some terminology here, that the terminology argues, everybody uses different things. So for example, Brad Frost who is awesome guy, and he wrote an amazing book called atomic design, which is around design systems. He talks about molecules and atoms and things like that and he's far cleverer than me, his way of thinking about it does my idea, right?

So I've got some kind of simplified version of it for today. So the first one is styles, styles covers things like typography, color layout, the basic kind of foundational stuff in a design, right? So that's your absolute basics, okay? So thinking about it from a Figma point of view, it's all stuff you set in the styles menu, basically.

Then up from that, there are elements. Elements are your buttons, your forms, those kind of basic building blocks of HTML. So if you think about HTML, other than the basic ones you have within HTML, P tags, H tags, Italic strong, those kinds of typographic ones, they would be styles.

But then alongside those, you have a whole load of elements like input elements, radio buttons, checkboxes, those kinds of elements, they would be elements in a design system, right? And then those come together you see are multiple elements that make up components, right? So components are bigger things like modals, Carousels, menus, and they're made up of multiple elements together.

Does that make sense? I think that feels fairly logical, especially if you come from a development background. Now, you could get even more complicated, and you could say, well, you could have components within components, and they are thing in their own right. So for example, a header, we might have a navigation component in it and a search component in it, so is that a thing in its own right?

But no, I would just say that's a component within a component. Because primarily, that's how Figma organizes it, right? That you can have nested components in Figma, so that I kinda stick with the same kinda wording.

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