Hey everyone. Hey, this video, we're going  to just wrap up our design tokens. We're gonna talk about when you should use them,  when you shouldn't use them. At what stage should you start using them? So let's jump in and do that now. So when would you use design tokens?

Um, you'll be using variables all the time. Okay. Because it has some useful stuff. Like, remember the advanced prototyping, where we're doing,  where we got to click a button and add it to the total. Um, we also did,  you'll also use it even if they're not being used in the  traditional design token kind of fashion. Okay?

So variables that do represent a color, color primary,  you might use 'em in new designs. You are using design tokens. Um, where they become more their full  design token self is when you're working with a large,  generally a larger business, okay? With a larger design system  that is generally the most useful is when you are working  with a development team. And generally that development team is internal. So you're working for a company large enough  to have its own internal UX design team  and development team, okay?

And the connection between you two are quite tight, okay? You might be working in even the same office, okay? So that the things you do flow  through the design team really nicely,  especially if you have, uh, going to different places. It's gonna iOS, it's gonna Android, it's going to web, okay? Lots of different places it might be going to design tokens  for consistency is perfect. So when would you not use design tokens?

Uh, for smaller jobs, styles work perfectly. The big drawback for styles is  that you can't reference them using aliases. But for lots of jobs, there's just no need to set up  that kind of complexity  with groups and different collections. Okay? 'cause it might not be that needed. Okay?

Generally those smaller jobs as well. Um, there is a disconnect between you  and the development team who's implementing  your design, okay? And you do not wanna spend a whole bunch  of time getting a design tokens, getting a structure,  naming conventions going only  to have the developer ignore them, grab your figment design,  this happens lows and go, uh, it's kind of about big,  you know, you've gone eight point grid  and they've gone, eh nine looks about right? Okay. And they've gone and build their own sizing. They'll, you build their own, they'll need  to build variables and they will build kind  of design tokens, okay?

But they'll build them in their own language, okay? Using their own kind of like way  and methodology, depending on  the way they've done the last job. The way that the framework is kind of structured already. So be sure if you are gonna put the effort into building  design tokens, okay? That the development side  of things are aware of what you're doing. You've got a consistent naming convention.

Otherwise they might just, yeah, ignore what all you've done  and do their own thing. Okay? So smaller jobs generally don't need design tokens. Larger jobs generally do, that's a good kind  of general rule. And the last one is, when does it get done? When do I start building these design tokens?

It's up to you. When you are  New at the concept stage, it's probably not that useful  to start building design tokens just yet, okay? Because you're, it's, it's about rapid prototyping,  not slow prototyping, okay? It's about just getting it out, getting it tested. What are the client thing? What's the feedback from the stakeholders?

Use styles to keep consistency. Okay? But don't be building out design tokens just yet, okay? Because often it's when you've got the final kind  of client sign off  or you know, the project's moving into development,  then you can spend some time getting everything nice. Okay? Working out a good system.

'cause you've got a sense of what the job is  and the scope of it is to kind of make an appropriate thing. Work with a development team at that stage. How do you name it? How do you want me to name it? Okay. Whether you are leading the naming  or kind of following what they're doing.

Generally it's done  after at least the, yeah,  you've got a good foundation of what you're doing. Okay? If you're working in an existing company  and you're doing this course, you'll have, uh,  a design system probably already. Or you'll have to kind of go through the old stuff  that they've got and build one out yourself. Okay? But it's done after all that kind of like fiddling  around, picking fonts and colors is already done.

And lastly, there is a lot of upfront work  with design tokens, but um, you know, the long term  usefulness of them is  amazing when you are working in a larger business. Okay? So yes, there's a lot of work up front. If you're thinking, man, it seems like a lot of work,  it kind of is until you've deployed kind of your design  and it's everywhere and then you have to go and make updates  and it's just a big headache  because this person that's got the WordPress blog  and this person who's managing the iOS app version,  they're all try, you're trying to like manage  and juggle them all, okay? Whereas if you've got a kind of a sound, uh, set  of naming conventions and design system, you can  makes it easier for everybody. Does that make sense?

There you go. A little bit waffly. I hope that helped you understand a bit of  what design tokens, where to use them when not to use them. There you go. That is it. I will see you in the next video.

Alright? I'm gonna go back inside the machine, got out  for a little while, back behind the screen. Let's talk. See you in the next video.