Objectives, Scope, and Groundwork

[00:00:00]
>> But if you have got buy-in, and if you haven't been told no, there's not time for it, you get in some agreement over the purpose of your design system is really important, so what's the main aim of doing it? Sometimes people create design systems cuz they wanna unify their brand and they know that different sites has ended up with different styling and there's a lot of inconsistency.

[00:00:28]
Sometimes it's more about streamlining development, in which case you wanna know that up front because that then needs to be the priority. So just a little bit of kind of definition, okay, what are we trying to achieve here? So we're not just jumping in and trying to do everything at once.

[00:00:46]
So it might be that you focus initially on, well, okay, let's just get everything working with the developers, right? So they can log into Figma and go, look, that's the so-and-so component, here's my code for that, I'll drop that in. If that's the initial aim, then you don't worry that the design isn't up to scratch or exactly what you want.

[00:01:07]
You get that working first, and then you can go back in and visually change the components afterwards. So knowing your purpose is really good, which kind of comes on to scope really. You also, I mean, this kind of one hand scope is like, well, do we care about sorting out the branding or is it just getting working the development?

[00:01:28]
But the other aspect of scope is, are we trying to work this for just a single project or all projects, right? So, especially if you work for a large organization like a bank, ideally, you'd like a design system that's a universal design system that can be used on everything from your native apps all the way through to your website, to your portals, to everything else.

[00:01:51]
Truth is, that's probably quite ambitious and will get bogged down and take forever to do. Most situations I recommend, look, just start small, yeah, just do it for the native mobile app, maybe even the iOS app and not the Android app as well. And you can get more ambitious over time, but until it gets really well established, if you let it bloat, it's like any project, isn't it?

[00:02:16]
If you let the project bloat, the bigger it becomes, the slower it moves to the point where nothing ever happens, right? You wanna keep it focused and keep the scope down. And also, what's your goal? Define what success looks like, is it a faster death cycle, improved user experience, increased brand consistency?

[00:02:35]
Where are you going there? There's a few questions to ask up front before you star any work on a design system, nothing particularly complicated, but it's all things worth considering before you get to kind of pulled in two things. One is accessibility, how does your design system ensure accessibility for all users?

[00:02:54]
You need to agree on aspects that you are gonna support, you're not gonna support, do you care about color contrast? Do you care about keyboard navigation? Do you care about screen reader support? It's really useful to know that up front, so you can build it in from day one.

[00:03:07]
I'm not making any judgments about whether you should be including those things, but you should absolutely be including those things. Second, versioning is a big one. This is a bit dull and a bit boring, but it's worth talking about. What's your strategy for managing updates and changes to your design system?

[00:03:27]
How are you gonna track a component's evolution, right? And let's say you've got a version of a component on your website, or your web app, and you've updated that component. Do you want to keep the legacy components are already on the web app? Or are you gonna replace all of them in one go to be the new version?

[00:03:50]
And what the consequences of doing that. So there's some thinking through to do there about, whether you're gonna have multiple versions of a component available. Or whether you're always just gonna go with the latest version of a component and that kind of stuff. Now that can all be managed with Figma has got version control built in, which is great.

[00:04:09]
And also I'll talk about some other tools that bring together design and development later that can help manage that kind of thing. But you need a conversation about it, yeah.
>> Yeah, for mobile, it's very sensitive. Because if there's users who have not decided to update their mobile app and they're pointing to older versions of the API.

[00:04:26]
>> Yeah.
>> And we don't wanna break them, so we are very, very sensitive to that.
>> Yeah, but some some organizations take the opposite with that, where they force people to upgrade. So they'll log into the app, and it'll say, sorry, you can't use this app until you've upgraded it.

[00:04:43]
I'm not saying that's right, but that's the kind of conversations you need to have.
>> Well, and the problem with that, though, is that people might have older phones-
>> That can't upgrade, yeah, yeah.
>> So we can't force them.
>> No, so the other thing is about responsiveness versus how responsive you want your components to be, cuz obviously they could be placed anywhere on the interface.

[00:05:07]
So if you've got multiple column design, some columns might be narrower than others, the whole design the expand and contracts or all of those components, are they gonna work at any size? What's the minimum size you expect them to work at? What's the maximum size you expect them to work at?

[00:05:26]
Should they work in every column type that you've got in your layout, etc? And then the final one is dark mode. And I don't just mean the whole interface changing to dark, but what if one of your components is put in a side menu that's got a dark background to it?

[00:05:41]
Can the component deal with that? Is that allowed? There's those kinds of things that need to be considered as well. So those are the big questions I tend to have knocking around, yeah, go for it.
>> So on the versioning, do some sort of rules or agreements about how to name files are how changes that occur on a Figma document.

[00:06:05]
>> Yeah.
>> Are those sorts of things does that fall under this category?
>> Yeah, I mean, again, it's one of those situations where you can over engineer and you can fret too much about all of that kind of stuff which you don't need to worry about in the early days.

[00:06:21]
Cuz you'll only have one version to begin with, but it's at least having a kind of sense of, well, how are we going to deal with versioning? Have the development team want to handle having multiple versions of a component? And then, how are we going to track that?

[00:06:37]
And then, once you've gone have got that agreement, then that goes on to, okay, well, how are we gonna name this? What version numbers are we gonna use, and things like that. But that can come a little bit later. So, normally, after I've kind of got a rough idea in my head of what my answers to these different questions are, if there's an existing app out there, and I do want to run a design systems project.

[00:07:07]
Even though earlier I said, well, maybe we wanna do it behind the scenes, but if we do wanna do it properly, then, yeah, you start by auditing your existing app, right? Review your current design and code assets, understand all the elements, colors, typography, UI components, the whole lot, and how they're being used across the site.

[00:07:27]
But also pay attention to gaps and inconsistencies, so identify discrepancies in the current design because there will be a lot, right? Here's an example, this is just some stuff I grabbed from one that I reviewed. And there were numerous different ways of showing filters and columns, sometimes buttons had icons, sometimes it didn't.

[00:07:53]
Sometimes buttons were joined together in bars other times they had separates between them, all of those kinds of things. So, all of that needs to be identified and listed. All of those different versions of them need to be sought out so that you can decide, well, what you're gonna standardize on.

[00:08:16]
So it does take a while to go through all of that thing, but not as long as you think you can usually do it in a day, depending on how less if it's not a particularly big thing. And all I do is, I literally go through every screen, and I do screen grabs, okay, of all the different components and elements on the screen, and then I start keeping a list.

[00:08:35]
And when that element appears on a second screen, but looks different, I group it with the first one, right? So buttons, here's all the different styles of buttons that I found across the site. It's as simple as that really. You can of course build as you go, which is what I was talking about earlier.

[00:08:54]
That said, there are some drawbacks to it, building components in isolation is quite hard, so I don't tend to do that way. Sometimes people go, right, we've got a new product we're building, let's start with a design system. And the designer is expected to sit down and go, okay, what is an input box look like on this?

[00:09:15]
Well, I don't really know, it depends on the context of how it appears within a page. Like I said, designers think holistically about stuff. So I would advise instead of mocking up a whole page and then breaking it down into components rather than going, okay, now I'm gonna style a button.

[00:09:34]
Okay, but let's say everything else around it looked like. Be focused, so by only building the, this is an advantage that, if you're only building the components that you actually need rather than the components that currently exist, that's great. Because you can keep your design system focused and streamlined, and not including stuff that isn't there.

[00:10:00]
And of course, all of this means it's faster and cheaper to produce. So there's a lot going for building as you go or building for a new service, but don't think you're gonna just, if it's a new service, you're gonna sit down and build those components individually, yeah.

[00:10:15]
>> Is what you're describing, the user interface designer doing their own design system.
>> I'm not quite sure, yes and no, right?
>> So when you say for example, you're doing a design system for a button.
>> Yes.
>> But then my designer might be like this, I don't know what the designer is thinking in terms of their button style.

[00:10:41]
>> Yeah, so-
>> Colors and their fonts-
>> What I'm saying it's that designer that should be creating the design system in conjunction with the developer to make sure that they're not doing anything stupid. [LAUGH] So but it would mainly be, yes, that the UI designer would sit down and go through and create the button, the links, link colors, the input fields, all of those things.

[00:11:08]
But what I'm saying is, is that them doing that just on each individual component by itself messes with your head, you got to think in terms of whole screens, otherwise, it's gonna throw you a little bit, make sense?
>> But isn't there some In terms of role of somebody just being a design systems person?

[00:11:27]
>> I would say no. I think it's good to have somebody that owns the design system, right, and is ultimately responsible for it. But basically, certainly from the design perspective, that is gonna be a UI designer, right? So let's say you had it there, and even then, I would say, let's say you work in an organization where you've got, I don't know, five different UI designers spread across different departments, right?

[00:11:59]
Not uncommon, I would suggest that, together, they could create the design system between them. One person ultimately owns it just so that you've got one person that's accountable, but anybody can put forward and submit a new component, right? So if they're working on something and go, we've got no component for that, right?

[00:12:21]
That I want to do, that's fine, they can create a new one, right? Or they might go, this component's no longer fit for purpose for whatever reason, then they can create a new one. And I'll come on to a minute about how to manage that, because obviously you can imagine chaos ensuing [LAUGH].

[00:12:38]
So I will touch on that in a minute.