Transcript from the "Design Systems" Lesson
[00:00:00]
>> And I guess the ultimate example of this collaboration between design and development is the design system and I do want to just touch on the idea of a design system. This is especially important when working on larger websites, but to be honest, these days even when I'm working on a small website I build a design system as I go.
[00:00:26] It just is the way that I work these days and I think it's very important when we think about that post-launch iteration and improvement to have a design system in here. I'm sure all of you know what a design system is, but it is a set of components and stars that helps you ensure consistency across the website.
[00:00:46] Why is it so important? Well, when we would, especially on larger sites, the design system will help multiple designers and developers quickly create new templates for a website of any size or new functionality for a website or web app and visualize those. It helps coordination between designers and developers.
[00:01:03] It helps standards between multiple designers. They're just really useful tools. In terms of when to use it, when to start creating it? Ideally, really from when you're right at the beginning of the project, start planning and design system as soon as you're working on the design. It's something that a lot of people try and retrofit after they've produced the design.
[00:01:26] And that's perfectly possible, but actually there is a huge advantage to doing it as you go in the sense that makes you think in terms of those components. And stops you ending up with lots of similar components that do basically the same thing. But you can create a design system anytime.
[00:01:51] I do work just to briefly reiterate what I believe should be quick key components of a design system. Styles is the obvious one styles include your typographic styles, so things like headings, quotations, links, color palettes, all that stuff. You've then got the elements which are the smallest element of a design system.
[00:02:14] I could start using Brad Frost's atomic design systems, but really, that's probably too granular for what we're getting into here. But basically, elements include the fundamental building blocks of a website. So these are things like buttons, form fields, navigation forms, and that thing, icons. And then there's the components, which are the more complex UI elements that make up a design.
[00:02:36] So I mean, you're looking at this thing. So you can see how the text, the insurmountable value is styled in a certain way. So that has a style associated with it. The quotation mark, the Chevron's, the pagination, they're all elements are small components and then together all of that the end of that block fits together into a quotation component that can be reused.
[00:03:03] I'm probably today going into way more detail than it's necessary, yeah.
>> Yeah, I have a question. I'm going from l a developer's side.
>> Yeah.
>> We have a design system
>> Yeah.
>> But sometimes. While talking to designers, they quickly come up with why their design has to be pixel, perfect.
[00:03:28]
>> Yeah.
>> Or like why they design is a special?
>> Yes.
>> How do you iron out that?
>> Yeah, it's really good when you snap them. [LAUGH] So there's this two different issues there. There's the Pixel Perfect issue, and then they're coming up with designs or design elements that aren't in the design system, all right?
[00:03:56] Let's deal with the pixel perfect thing first I mean, essentially that one it comes down to that's not how the web works, all right? And especially in the world of responsive design those pixel values just don't exist in that way, all right? So that's a bit of a frustrating one because that's not a difference of opinion, that's a difference of fact.
[00:04:29] [LAUGH] Pixel perfect design is not possible on the web, why are we even discussing this. So it's a bit hard to argue with that one. It probably is an indication they come from a print background and in which case I think I tend to announce situations, start talking a lot about responsiveness, a lot about the different sizes.
[00:04:51] I talk a lot about the accessibility and the fact that people resize their, like for me as I've reached 50 now, and I'm getting long reading glass I have to wear reading glasses. So I've increased the font size on everything which obviously completely mucks up anybody's design, all right?
[00:05:10] So it's exposing them to those scenarios that help deal with that. In terms of that are this is a component we don't currently have, I think that's. That is really an educational piece in terms of wire design system exist and how it benefits everybody, all right? So if a design system is set, you have a design system as a development team.
[00:05:39] But if they're not using it within the design department, they're not getting any value out of it. It's just a barrier to them, all right? But once they've got the design system set up in Figma, as well Suddenly it's a huge boon to them. They can produce designs and mock-ups much quicker, and the temptation on their part just to use an existing component rather than create a whole new thing is huge because it's easy.
[00:06:01] I could do that in seconds rather than however long it takes me to great something custom. So the key though, I think, is to get them set up with the design system in Figma for them, all right? So they've got all of those components, and they can interact with them.
[00:06:16] Then you'll find that they naturally start using those more. When they do want to create a component that doesn't currently exist in the design system. That's fine, all right? That's, okay? A design system is a living, breathing document and does change over time. But there are cost implications of that, all right?
[00:06:35] That's gonna take you a lot more development time than it is going to take just to use an existing component. So in that case, it's a matter of they need to create a business case for it, all right? Simple as that, they need to justify that particular element, all right?
[00:06:51] Why that element has to be done in the way it's done to offset the additional hours work or however long it will take to do that. And they just need to be able to show that even, anecdotally, all right? We're not gonna make them do a whole business case, but there needs to be some justification.
[00:07:07] And then it's not just done as a one-off element, all right? It's done, it becomes a new component. So they can't just go, well, we only need it here. Well, if we only need it here it's really not worth the developer's time to build it cuz it a one of use case.
[00:07:25] If it's an entirely new component that could be used across the whole site then that's more justifiable, all right? So that kinda pushes their thinking towards this mutual base thinking. But to be honest the big win if you just get them set up in Figma with these elements already built in they'll just use them because it's easiest.
[00:07:46] Does that help in any way?
>> Yeah.
>> It's not a black and white simple answer but, yeah. Okay, so yeah, let's talk about organizing our design systems because that begins to think about what in your case, for example, you've got to introduce that into the design side.
[00:08:06] Sometimes you're starting completely from scratch. In either cases, I would say look, start simple, don't if you've got like loads of components probably don't try and put all of them in Figma in one go because it'll take too long. [LAUGH] So just pick the most common ones and create them to get them going.
[00:08:26] Even if to begin with you do nothing other than set up a few styles, not even components, but just here's the color palette. Here's the typography so that you don't have to pick the color palette color every time you go, that's, target red or whatever that thing makes a big difference.
[00:08:45] And then add the really basic components start with things like the header and the footer so that he can just drop those in really easily and then just add to it over time. It's a bit of, it messes with your mind working on a design system. I don't know whether you found that, but you can often overthink them.
[00:09:05] I think one of the common problems with design systems is they need to strike the balance between having too many components where you end up with components for everything. Or completely abstracting the components so that they fundamentally become meaningless. So for example, it would be okay to have a separate news component, a news listing and an events listing even though really they're probably quite similar in terms of fields and stuff.
[00:09:36] And that's especially true with the designer side. From your point of view, from a developer point of view, you want to do that abstraction, all right? Because you want to keep the code as lean as possible. You want as little, tables in the database or whatever it is you do, I don't really understand.
[00:09:53] But from a designer point of view, I wanna create mock-ups. So having a news listing mock-up and events listing component the two separate components that makes it easier for me to create those mock-ups quickly. Even though on your side, you probably use the same code and database for both.
[00:10:09] You see what I mean? So sometimes there is, you got to strike that balance. I don't know whether any of that makes sense, but hopefully it did. And then finally, I'd say stay flexible. Your design system should evolve. You'll be adding new components when you need to, as they come up, but also seek to combine components when your system starts to become too bloated, that's normally a signal that you need to move things on.
[00:10:36] In terms of keeping your design and your code components in sync with one another, which is a huge problem. It's been solved thankfully by a tool called zipline that I don't know whether you've checked out, but it's really good integrates straight with Figma. And you can basically see the code and what the element actually looks like side by side.
[00:11:03] And it will keep them all in sync and stuff like that is really, good for this thing. Managing this stuff, and together it makes it really powerful is a way for a designer to quickly mock up a page. And a developer to go, well that page is made up of this component, this component, this component, this component or just grab those put it in job done.
[00:11:25] That's where you're trying to get to basically, but actually a big area people overlook when it comes to design systems and components is actually the benefit that it has to your content creators as well. So, for example, my own website which is just built on WordPress, all right?
[00:11:43] And it's only my site, yet he's still got a design system behind it. Seems like a sledgehammer to crack a nut but what it enables me to do is I can add in things really simply using Gutenberg blocks. So for example, we've got a component on the screen here which is just a quote that can be shared on Twitter.
[00:12:05] And I built a custom block really, really simple custom block that basically allows me to put in that content, and it will display it in that way. So you can use actually that component mindset and that basic design system even on a tiny little site, it doesn't need to be on a big site.
[00:12:23] The other thing I would say with a design system is a design system can go much further than maybe you think it can. I've written an article on this, and I'll let you check it out in your own time and read through it. But a lot of people when people think of a design system, they're thinking of a set of UI components, all right?
[00:12:44] But I would say that a design system is a lot more than that. Or at least it's got the potential to be that a design system is a way of systemizing design as the name implies, and that isn't just about the UI components. Or other things on the go here, for example, those design principles I talked about, all right?
[00:13:06] Those are a part of a design system in my view, they are part of the decision-making process ,part of the infrastructure around which your principles can be created a content style guide. Really, that's a part of the design system as well, it's the design of the content and how the content integrates into it.
[00:13:28] And even something like a service manual or digital play book, which documents how digital is run, how your projects are run, all of that could be a part of your design system as well. So, if you have a design system already, I'd encourage you to maybe expand it beyond just the UI components that everybody thinks of.
[00:13:46] And actually think of it more holistically in terms of how you're running projects, and how is that dealt with, what your design principles, what's your content guide, all of that stuff. So yeah, all of these things you can be developing alongside your build or post launch if you need to.