Building a Design System

[00:00:00]
>> So how do you actually build a system? This is kind of the general flow. So you define your design principles, conduct a UI audit, create your checklist, and define your workflows. So let's kind of examine what all of these mean. Design principles are really the grounding values that drive the creation of your products.

[00:00:18]
And they really encompass the question like, what do you want your users to feel when they use your product? And this is gonna drive the creation of your components. So if someone comes with a proposition for a new component and it doesn't fit with your design principles say, this isn't gonna work, it's not gonna work with our system.

[00:00:37]
So this is a design principle from Atlassian. And there's as bold, optimistic, and practical. So that's the first step, define your design principles. What do you want your users to feel when they use your application? So most of us are probably working on legacy applications that already exists.

[00:00:55]
You're probably not building a design system in a silo from scratch. And what that means is your UI is probably comprised of a lot of different combinations of components. And so, the next step is a UI audit. So you need to go through your UI, through your products.

[00:01:11]
Take screenshots of every component in every single state that exists and throw it into a common place, whether that's a sketch file, a figma file, a Google Drive, something or other. And then you group them by functionality. We're not gonna group them by visual appearance, because visual appearance can kind of change and evolve over time, but the functionality, the underlying functionality is gonna be the same.

[00:01:33]
So once we conduct our UI audit, we actually have to prioritize, we're gonna have a lot of components. How do we actually pick and choose what we're gonna work on first, especially if we don't have a dedicated design team or if we don't have that many team members?

[00:01:45]
So we need to figure out how to prioritize them. And we wanna focus on the things that are gonna have the highest impact and be easily achievable. So some of the questions you're gonna wanna ask yourself and I like to put these in a survey, an online survey that you can give to product management to design and engineering and have all of them take these surveys.

[00:02:04]
Because in integrating a new component to your system does not just impact design, it doesn't just impact engineering, it's gonna impact all of them. So you need to kind of make sure that all three areas are really covered. And these are some of the questions you might wanna ask.

[00:02:18]
Does this request or does this component embody our design principles? Is this going to require a lot of design or development effort? Does this come with a high risk to the success of our product? Is it gonna break things potentially? Does this coincide with our product roadmap? Is this something that we can actually fit into our current workflow?

[00:02:41]
Is this going to actually improve the UX of our products? Is this is gonna make our users lives better? Are we confident in this decision or is it gonna have to be revisited in the near future? And is this technically feasible? If we can't build it, we shouldn't even be wasting time on it.

[00:02:59]
So we can kinda take these statements, or take these questions and turn them into impact statements. And then we're gonna evaluate them on some metrics. So we've got two different kinds of metrics. We have adoption metrics that indicate this component should be prioritized. This is a great component to integrate.

[00:03:15]
And we have opposition metrics. So these are ones that are saying, well, you might wanna actually not focus on this right now, it has a lower priority. And we're gonna examine these from impact, identity, and competence, and maintenance, risk and effort. Those are the metric areas. This is a lot, this is a big slide.

[00:03:32]
But this is essentially telling you how you can calculate the priority of a component and actually plot this on a graph. And why this is great is you're gonna have a lot of stakeholders, people are going to be watching your system. And oftentimes, this is twofold. One is, you will get people who question your decisions and one is why you've prioritized component A over B.

[00:03:50]
And this gives you a mathematical equation actually tell them this is why. This was super risky to do, this is gonna take a long time to build. So it's less of a priority than different component. So essentially you're gonna create these impact statements. You're gonna have your designers, your engineers, your product managers, all take a survey that kind of evaluates these metrics.

[00:04:10]
And you're gonna get this an adopter score and an opposer score. So what's the priority? Should it be a high priority? Should it be a low priority? And we're just basically gonna like average these together across all people who've taken this. And we're gonna get an X, Y value out of this, and we can plot that on a graph.

[00:04:27]
It's gonna be a four quadrant graph. So in the top right, we've got priority one. This means it's a strong adopter and it's a weak opposer. And these are wins, right? If something is gonna be really impactful on unifying our UIs and our products, and it's really not very risky, it's not gonna require a lot of maintenance.

[00:04:45]
Yeah, let's focus on that, that's great. Priority two, in the bottom right, the strong adopter, but it's also a strong opposer. So maybe it's going to require a lot of maintenance. In that case, maybe try to mitigate the opposition. What the nice thing about this is you can point to exactly the opposition metric.

[00:05:03]
That's the issue, like you can say, maintenance is gonna be a huge issue or I don't remember what my other metrics were. But you can point to the exact metric that is the problem and maybe try to do something to fix that and get it up into the top right quadrant.

[00:05:17]
Priority three are weak adopters, weak opposers. So you're gonna wanna focus on the other components before starting these. And then parking lot I don't like to say throw them out, cuz no idea is a bad idea. But these are kinda things that aren't gonna give you a lot of benefit, but they have a lot of risk associated or maintenance associated and should be kind of just put off to the side until you need something else to work on.

[00:05:40]
So let's take a little example. So buttons, let's say we go through this whole process, we have our designers, our engineers, our product managers. All take this survey and let's say we get an average score of four, four out of five point. It will put it up in this upper right quadrant, priority one.

[00:05:56]
So buttons are gonna have a high impact, they're really gonna unify our products and they're gonna help brand identity. They do however, require a lot of maintenance and effort. They might have to be revisited a couple of times in terms of styling and things like that, but they're gonna have a good impact.

[00:06:12]
So those maybe be priority one. And let´s take something like an accordion. You're probably not gonna use accordion through out your products too often, right? Buttons are definitely gonna be used a lot more. And accordions are complex, they're not a native HTML element or a semantic element that you can just instantiate and it works.

[00:06:31]
There's something you have to build, you have to add accessibility concerns, the way and make sure it's accessible, and things like that. So it would be a low adopter. And we shouldn't focus on that as much as buttons, or other four elements for example. So this is kind of how you can mathematically graph the priority of your components and give that to stakeholders and be like, hey, here's our priority list and this is why.