Planning Your Design System

[00:00:00]
>> So those are the three building blocks of it. How do you then plan your design system because it's quite an intimidating thing building a design system. It doesn't sound like many of you have done it. Some of you are trying to do it and if you're trying to do it, you know that it's scary.

[00:00:17]
So little bit of advice about how to go about planning my first piece of advice is don't buy in a design system, right? Is so tempting, right? Because you can go out there and you can find these design systems ready done all the elements, all the components you want all the colors and styles and everything.

[00:00:38]
It's all just there and I can just go yeah, let's have that, right? Now I'm talking from the design point of view, I can't comment from a development point of view. I know a lot of developers use things like Bootstrap and various other things and build on that.

[00:00:55]
I can't comment on whether that is a good plan or not. My gut says it isn't. But who am I to judge when I'm not a full-time developer anymore. So why don't we wanna do it from a design point of view? Well, reason number one, they're over engineered, right?

[00:01:12]
And that's not a criticism of them they have to be, they have to build a design system that they can sell to anybody, right? So that means they need every single element or component that you might ever need in it, okay? But your needs are probably for only a small subset of all of that.

[00:01:31]
So you've got all this extra stuff in there that you don't actually need there and it just gets in the way basically and causes confusion and difficulty, right? And because it's got so much in and it's so over-engineered for your needs, it takes forever to learn, right? And get your head around how it's working.

[00:01:52]
And of course the mental model of the person that created it is different to your mental model and how you're thinking about it. And you're going, blimming heck, I've got to kind of pick through all of this and understand it and in the end, you get to a point of going you know what I think it'd be quicker to build my own, right?

[00:02:07]
And you can tell here that I'm saying this from personal, horrible [LAUGH] experience of going down this road. Also, they're gonna need heavy customization, right? So then you've got to understand how all of these components interlink with one another and how they reference one another in order to be able to edit them and customize them.

[00:02:27]
And that can be a challenge in its own, right? And in my experience, they can often really result in bloated code as well. Because again, you've got these components built into the system that you don't need in your use case, but they're in there anyway. And this design system gets passed across to the developer and if the developer isn't really on the ball because he's too busy or whatever else, you could easily end up with all this stuff being built, you don't really need.

[00:02:57]
All of that said there is a caveat, right? Which is that I do sometimes buy a design system just to speed up the creation of my own design system, right? So for example, instead of creating an input box, a radial box, all that kind of stuff. I literally got a design system that I bought ages ago.

[00:03:19]
I go in, grab the input box shove it into my design system, customize it the way I want and add it in like that. But I never would take one wholesale. And even that, sometimes it's like, I'll just do it myself. So it's a false economy at the end of the day.

[00:03:40]
Personally, I feel like it is maybe other people have managed to make it work, yeah
>> Well, what about referencing the design systems that are online? I mean that's one of the other things there's a lot of an open source right now like IBM's carbon design
>> Yeah, again I advise against using those, right?

[00:04:08]
For all the reasons I've just listed.
>> For selectively, in terms of designing a component and looking for some practices, would that be [CROSSTALK]
>> Yeah, no sorry, I understand you. I didn't understand the question. Yeah, absolutely I often look at other people and rip them of. What is it?

[00:04:24]
We're building on the shoulders of giants or some other way of justifying the fact that I'm just copying somebody else's work. Yeah, no, I do that all the time.
>> Well, one advice about design systems I heard, don't try to design it yourself. Learn from what is there because whatever you're gonna try to come up with probably not gonna be the best.

[00:04:43]
>> Yeah, I would agree with that regards. I'm talking more about actually building it, right? Actually creating the components and the elements in something like Figma. That if you buy in a design system that you can just plug straight into Figma that you're not gonna understand. I'm happy to learn from other people.

[00:05:05]
I'm happy to copy from other people where it's relevant, right? But it is making no and then I build it myself. I recreate it in Figma myself so that I understand what I've done. And by doing it on almost a component by component element by element basis. I can choose to what what to include, what to edit, or what to go, I don't need that at all.

[00:05:32]
Well, when you buy something in, you've got it all whether you like it or not, right? So that's my kind of logic, yeah.
>> And I can speak from an engineering perspective too. There's actually an article that Josh Comeau wrote for Smashing Magazine two years ago where he said essentially the same thing.

[00:05:50]
It overcomplicates the engineering process. And that's the case with when I've used material UI. Initially it seems very easy to get going but as the application scales and you need to remove elements, or you wanna customize behavior it quickly breaks down.
>> Yeah.
>> And then you have to throw everything out and start from scratch so

[00:06:12]
>> Yeah, and that's certainly been my experience working with engineers that it reaches it. But it's great for getting started quick but it causes problems further down the line. And yeah, I'm not criticizing people that buy in a solution to get going quick. I understand that desire. But from the design perspective, I don't even think it allows you to start quick really.

[00:06:39]
Because you're spend so much time getting it into shape that it probably won't work for you anyway. The other thing I would say is quite important is from a design perspective is get buy-in upfront. I need to clarify what I mean by that. It's a bit of a misleading title, to be honest with this slide.

[00:06:58]
What I mean is collaborate, right? In the creation of a design system, don't just go and kinda create a load of components in Figma. But actually, work alongside your developers on it and engage with them and your product managers and people like that. Because they've all got to live with it, right?

[00:07:22]
What works for you might not work from a development point of view. And if it's gonna make handover difficult between design and development, then you're losing half the benefits of having a design system. So it's kind of ridiculous to create a Figma design system without at least involving the developers.

[00:07:40]
So now, it might be the developers are ahead of you, which is really annoying when they are and they've already created a kind of design system in code. And in which case, you really need to replicate that and use that as the basis from for building your elements.

[00:07:58]
Because they will be better than you so just suck it up. And then you obviously you can change the appearance of those and stuff like that. But developers, developers do this kind of stuff by default design system is essentially object orientated, which has been around for like forever.

[00:08:19]
So when you suddenly get these designers pop up and go, yes, I think we need a design system. And all the developers are sitting there going, we've been doing that for donkey's years. So really listen to them and get them involved in it as well. And the other the other reason to get buy-in upfront is just to sell the idea.

[00:08:40]
It's surely your executive and your team can see the value of your design system and how it's gonna help the organization. And talk through those cost savings and the brand consistency in the faster time to market. It really helps to get buy-in but oftentimes we will have reluctant managers, right?

[00:09:02]
And we'll hit this barrier of, well, we don't have time to do a design system. We need to push out this next feature and the never-ending kind of thing that goes in there. So and it can be really frustrating. And it's like you're just making everybody, you're slowing us all down by not having this thing in place.

[00:09:22]
So when that does happen and when I really can't get anywhere with managers, I just go stealth. [LAUGH] So a manager doesn't know whether mocking up a design screen takes two hours or three hours. So make it take three hours and then spend the extra hour turning every element that you create on that page into a component, right?

[00:09:45]
There's a lot of thoughts, right? We need to have a design system project, right? Where we build our design system from scratch but you can actually build it as you go along, right? When you mockup a screen make sure you turn, if you create a component make sure it's then added to a component library and that's the beginning of a design system.

[00:10:07]
It'll need to tidy up at some point but that's further down the line, right? And if you keep adding more and more of these components to the design system over the time you get a design system by default really. Just by spending a little bit longer every time you mockup a screen.

[00:10:24]
There's also a good argument to say, well actually maybe that's the right way to do it anyway. Because if you do a design system project you sit down and you have to come up with all the components you need, right? And so, what you end up doing is auditing the existing website that takes ages.

[00:10:42]
You then build all those components and then half of them you never use again. Well, if you're only building them as you require them, actually you're only building the ones you need. There's a little bit of groundwork with your styling. That needs to be done separately and your main elements.

[00:10:58]
But why even the elements you can kinda do as you go, I need an input element. Let's design an input element and we'll put that cross in the design system. Keep that for next time I need it, right? So it's like squirreling away design elements and when I want them later, yeah?

[00:11:15]
So just don't tell anyone. It's my advice, just do it.