Implementing and Evolving

[00:00:00]
>> So that's a little bit of advice around design systems. I do wanna just briefly, as we come to the end here, talk about implementing and evolving your design system over time. The one thing I would suggest is, I wanted to say a bit about turning components into code, right?

[00:00:20]
A lot of organizations will do one or the other, right? Either you'll have developers who have all been all proactive, and they've created a design system with components in their code. Or you have a design team that have built a design system in Figma to make their lives easier.

[00:00:38]
Or, oftentimes as well, both have done that, but neither have talked to one another, and so it's two completely different systems. The real power of design systems is where you have a one-to-one match, a component in Figma with associated code with it, right? So a developer can look at Figma and go, that's a so-and-so component, let's grab the code for that and whack it in.

[00:01:03]
That's where you get the real benefits. So having a repository that links those two so you can see how the two work together is really helpful. Now, there are no shortage of options available to you here. The one that I use is one called ZeroHeight, which allows you to link your design components to your code base.

[00:01:26]
That's my personal preference. However, I noticed Steven in one of his, yeah, it's Steven, in one of his talks uses Storybook, which I'd never heard of, right? So you might wanna take a look at that as well, as Steve teaches you how to use Storybook, while I've taught you nothing about how to use ZeroHeight.

[00:01:44]
So you might wanna go with his option. But these are really powerful and absolutely essential. The other thing I would say is, your design system's never done, right? So don't think of it as a static document, but think of it as a living, breathing thing that will evolve over time.

[00:02:05]
For a start, you'll get user feedback, right? User feedback every now and again will highlight improvements to your design system or something gets revealed in in some usability testing or something like that. And you will need to do a second or third version of a design component to get it right.

[00:02:25]
Also then of course, organizations love to change their brand every 30 seconds. So every time they do that, we've gotta update all of our components to fix that. However, most brand updates in my experience, consist of changing the colors, changing the logo, and maybe changing some styling, like drop shadows and rounded corners.

[00:02:44]
Well, we've set all of those things. Your logo will be a component, right? So that means you can just go in and replace it, and it'll ripple through the whole lot, everywhere. The colors are set as variables, so you can replace it in the variables and it'll ripple through everywhere.

[00:03:00]
And the rounded corners and the shadows are all set as styles, so again, it'll ripple through everywhere. So actually rebranding an entire site becomes quite straightforward if it's built with the design system in place. But then, of course, there'll be new features and functionalities that you'll wanna add as an organization.

[00:03:22]
So how do we go about adding these new components? We can't let it be wild west, that anybody can just go along and create a new component. Otherwise you'll have more and more components being added and nobody will be looking after them and it'll be a nightmare. So I'm in a little bit of a process for adding your new components is worthwhile.

[00:03:40]
Little bit upfront research before you agree to a new component is great. Doesn't need to be much, you just need to ask a series of questions. Can we use an existing component, right? It's amazing how often people wanna jump in and create a new component when actually, all you need to do is restyle an existing component, right?

[00:04:03]
So oftentimes, you can actually just reuse an existing one but add a layer of styling over the top of it. Other times it's, can we revise an existing component? So could we change this component to meet this new need and then roll it out to every other occurrence of that component as well.

[00:04:24]
And the other one that you need to ask is, if you've got people spread across the organization is, is anyone working on anything like this at the moment? [LAUGH] Cuz the number of times you've got two designers working on the same component in different places and nobody's talked to one another, I cannot express it.

[00:04:40]
So just ask that question. Then it's a matter of designing your new component, if there is a need for a one, iterating it, testing it. Then it's handed across to development, who code it up. You wanna document it, get it into your ZeroHeight or Storybook system. And then just Make sure everybody that is aware of this component, has a chance to review it and to approve it, just to have a little bit of structure in place for ensuring that it's not a wild west.

[00:05:14]
Talking about version control, we were talking about verse earlier and you were asking about naming conventions and stuff like that. A little bit of vice around that, having a clear versioning strategy, fairly obvious, establish a clear and consistent approach for how you're gonna do it. Make sure you document any changes that you're making as you go.

[00:05:37]
I know it's boring writing documentation, but it's so helpful when you get turnover of staff. And documentation should be more than a comment in your code, developers, looking at you. [LAUGH] You should have a rollout strategy, so what's your process of rolling out new ones? And will they replace the previous one universally?

[00:06:05]
How are you gonna deal with that? A depreciation strategy is worth having as well. So basically, if you're gonna retire a component, what's it gonna be replaced with? What's your timeline for doing that? What's your alternative? How are you gonna communicate that with the rest of the organization?

[00:06:22]
And then, access to previous versions is quite important. You might think you'll never need it again, you will. So make sure it's available somewhere, archived away. Adoption and communication is quite key when it comes to design systems. So you gotta sell your design system, cuz you create this design system, if nobody uses it, you've wasted your time.

[00:06:47]
So you wanna be communicating the value of it, you wanna give people a sense of ownership and the ability to influence its direction. There's nothing worse, designers, and I think developers in my experience, but designers definitely, they will rebel majorly if you force the design system on them, right?

[00:07:06]
They throw a tantrum, there's tears and it's horrible. So got to bring them along with you, right? Get them involved in the creation process. It's great to have champions, some people that are gonna really champion the design system and advocate for it. And you also wanna consider training and support, especially if you use outside agencies and you need them to work with your design system.

[00:07:32]
So think about that and how you're gonna do that.