The Who, When, Why, and What of Design Systems

Alright, hi Web Directions!

I'm really excited to be here and I'm also super excited because this is the first official talk for the new design systems track.

I'm a very big lover of design systems and I work with them all throughout my career, so let's get started shall we?

Should we just dig into it?

Alright, so hands up in the crowd who actually knows what a design system is?

Okay, yeah, probably most of you raised your hands, so why are you even here?

I'm joking, hopefully we've got some stuff for you.

But we've got here, a design system is a collection of reusable components guided by clear standards that can be assembled together to build any number of digital products.

It's a pretty good quote there, but, I think we can do a little bit better.

So I've got a little example here.

Geez, that really brightened the room, didn't it?

We've got an example here with the tree, right?

So we've got the user interface, the UI, which is what most people see and think about with design systems.

Okay, so those UI kits.

And realistically, a design system, it's so much more.

So you can see, we've got the big green tree at the top with the user interface, and below, we've got all the roots and that is really where the design system lays, right?

There's so much more to the design systems.

You've got the iconography, you've got design tokens, typography, the communication, branding, everything.

There's so much that is involved and it's not just that user interface element.

To go through all of these little building blocks, and obviously I can't reach all of them, I'm going to be doing it and talking about the who, why, when, and what.

So who is your team, who should the design system owner be, why do you even need a design system, when should you build one, and then what do you need to do, right?

So what do you need to plan, what do you need to research, and what do you need to build?

Who is your team?

Who are your collaborators?

Because there's going to be so many people who are involved in your design system throughout its lifetime, okay?

From start to finish.

And I shouldn't even say finish because a design system is constantly evolving, right?

So it never really finishes.

Hands up here, who's a designer?

Not as many as I thought.

Interesting.

Alright, what about developer?

Yay!

Alright, we've got some developers in the crowd, that's really good.

Here are the two main contributors to a design system.

Okay, they're constantly working together, always.

Whether or not they'll be building the design system at the beginning, or actually using the design system to create that product at the end.

We've also probably got some product and project managers who are involved, and depending on the company structure, these are the people who are actually going to be, you might be reporting to, right?

If you're reporting to them, it's really important that you're pushing the design system so that they know the benefits of the design system and that they can advocate for you as well.

You might have some researchers, so some user researchers involved, and these are the people who reach out to your products' users, okay, so users are super important when it comes to design systems and they're going to bake those user beliefs into the design system from the very beginning.

You also might have some marketing or brand team or you might not have a team or even one person, you might actually just have a logo.

And a bit of a style guide.

So if that's the case, that's all that you need, but you still need to collaborate with that and include it into your design system.

You probably, if you're really lucky, you're going to have some content and copywriters.

Okay.

And these are the people who are going to be obviously producing the content for your design system, but also for the product at the end.

So utilizing those people to actually help you with the structure, so the beginning of your design system.

So they might be able to help you out with things like voice and tone, which you know, doesn't sound so important right now, but it is gonna be in the long run if you want your product to succeed.

And again, one last one.

Accessibility experts.

Now this might just be a person, but it actually might just be, on the shoulders of every single other person above.

So the designers making sure that your color is contrast and accessible, the developers making sure that your code is accessible, and so forth.

So it might not just be a person, it might actually just be, the responsibility might lay on everyone else.

And that's okay.

So this is your team.

Obviously you've got many more people who are going to be involved.

These are your main ones.

Now you've got your team.

Who in that team is going to be the design system owner?

Okay, so we've got three main ownership models that I'm going to talk to you about today.

All right, and the first one is solitary.

Now, what this means is that the design system, it relies basically on just the one person.

So I'll give you an example.

Over in the UK, I worked for a start up called DaCast, and DaCast, they hired me to create the design system.

They already had products, but they didn't have a design system.

I was the one who built and then maintained and used the design system as a designer.

And that was all on my shoulders.

So this is called a solitary model.

Okay, and it works okay when it comes to those smaller companies, but as soon as you start to grow, it can become a bit of an issue, which is probably why you want to then have a chat and see if you can move up to one of the next models.

So next ownership model is called the centralized approach.

And this is where you have a whole team that is involved in the construction and also the development and maintenance of the design system.

You might not just have designers, you might also have developers and product people all in the one team and their sole purpose is to, organize and that with their design system.

Okay, so this is a centralized model.

And last up, we've got a federated model.

And the centralized and federated, they work really well for those medium to large size companies.

And this federated approach, basically what it means is that you don't have the one person doing who is in charge or a whole team.

You've got people all across the company who are actually involved in the design system.

So it doesn't just rely on one person or one team.

You've got all these people who are involved and they might meet regularly.

Okay.

To chat about the design system, approve maybe some components that need to get improved and help with this maintenance.

So as long as you have a really good governance model in, in check there, then this also works quite well.

So those are our three different ownership models.

But you might be asking, why do you even need a design system?

There are four advantages, so four key purposes to a design system.

And the first one is quality, right?

So it guarantees the quality of your digital product by establishing design and usability standards, incorporating user feedback and ensuring accessibility.

Second, it maintains consistency throughout your product and its new features, ensuring that long term success.

Third up, we've got efficiency.

It enhances efficiency by providing designers and developers with those pre designed components and guidelines, saving time and promoting collaboration.

And last up, you've got scale, okay?

As your product or organization grows, the design system scales with you, adapting to change and to the new features.

I'd say that those are pretty good benefits.

Design systems streamline collaboration and communication and help teams deliver a higher quality user experience within a shorter period of time.

Write this down guys.

This is what you need to be telling the people who are going to be approving your design system.

I'm going to repeat it just once more for you.

Design systems streamline collaboration and communication and help teams deliver a higher quality user experience within a shorter period of time.

I'd say that's pretty damn amazing.

All right, so when?

When should you build a design system?

As long as you don't have, I don't know, limited resources.

You don't have enough budget, you don't have enough people.

Maybe you have a highly customized interface.

It's probably not important to do a design system with that.

Or maybe it's a solo project or a temporary project.

Probably not, any purpose of having a design system for that.

But, for everything else, you need a design system.

Do you have a new product?

You need a design system.

Do you have an existing product that doesn't have one?

Or you've got a really shit design system?

Get a design system.

Alright, so it's never too late, especially for those existing products, to get involved and to build those design systems, alright?

We already showed you the benefits of them.

The next bit is the what, and I've split that into three sections, I've got the research, what do you need to research, what do you need to plan, and then what do you need to build.

Alright, I've got a nice little grab up here from the component gallery, go check them out.

So the first thing you want to do when you're researching.

You need to understand your users and also your competitors, right?

So you really need to draw inspiration from all of the design systems that are around you.

So this is where this comes in.

This has got hundreds and hundreds of design systems on board.

You can go in there and they don't just show you the product, they're showing you the design system.

They're showing you each individual component that they've got on their screens.

They're showing you their documentation.

It's pretty amazing.

Okay.

So these are like open source products and you can take from them.

Okay, so these design systems when you're doing a competitive analysis you can go on and you can look at the products that will be similar to your product.

All right so you can have a look see who your competitors are or maybe even just have a look at all the design systems and choose ones that inspire you or that it's a similar style to what you want to achieve and then once you've done that you know, you can take a look at all of those little components that you like and, take them, copy them.

Don't be embarrassed.

They've already done this before.

They've done all the user research.

They've done all the hard work for you.

Okay, guys?

If it's out there, take it on board and, style it into your own design system.

Now, there are a few design systems that I would like to mention, okay?

There are some really big ones, like Google Material Design, you've got Atlassian's design system, or IBM's Carbon design system, or if you're looking into government, you've got the Australian Gold design system, which was based off the DTA, or even we've got Agriculture design system, which is one that I use at the moment, and I know that we've got some people speaking who are actually from Department of Agriculture.

That's pretty exciting.

And one of my favorites is actually the UK government's design system, all So these are major people, major companies, and major government bodies that are helping you because they've already done this hard work, all right.

Next up is an interface inventory.

Be prepared for some tears because interfaces inventories, this is something that you're going to want to do if you've already got an established product but you don't have a design system, okay.

So if you've got your design system, sorry, if you've got your product and you want to start on your design system, you start with the interface inventory, and you're basically going to want to screen grab all of the little components that you've got within your product, alright?

Your buttons, which you can see up here, okay?

Your check boxes, your text, your colors, your typography, every single little user interface component, you're going to want to screen grab.

Then you can categorize them, put them into their places, navigation, forms, etc.

So you can do all that and then you get a general idea of what you've got to work with, okay?

What aspects do you actually want to keep and which ones you want to chuck in the drain because they're really horrible.

Now, I've done interface inventories before for products where what on the screen is reality, okay?

So you might have 30 plus variants of the same component.

Up here on the screen we've got Brad Frost's interface inventory, go check him out.

So this is a screen grab from him and you might think it's a joke, but it's not.

This is reality for some products, okay?

And this is why you need a design system.

Because every single time a designer is asked to do, a mock up for a page, or the developer is asked to do and develop a page, they're never going to have the same mindset, alright?

Everyone's always going to look differently at things, and they're always going to produce something different.

Unless you have those pre built components behind you, and you have those guidelines, you're So this is why you need to do an interface inventory.

Alright, next up, we've got some boring stuff.

I'm really sorry guys, but You're gonna need to plan your design system, and I know all the designers and developers, all we want to do is design and develop, and I get that.

Planning is really important, and unfortunately, file structure is one of those really boring ones.

I thought I'd just, get in there.

So file structure.

Now I'm never, I'm not going to be talking about a specific design tool today.

All right.

So no Figma, no Adobe, nothing like that.

This is just how you want to structure your files and your folders.

Okay.

And whether or not you do that in Figma or not, it's up to you.

So the base of your design system is your styles, your colors, your icons, and your typography.

Okay.

Then once you've got all those ones, You could have them all in one file if you wanted to, but if you're going to scale and grow your product, it's probably best to have them as separate files.

That way, if they get too big, you don't have to separate them off later.

Then you're going to have the biggest file of them all, which is the components.

Okay, so components are all your things like your buttons, your drop downs, etc.

That's going to be a really massive file, guys.

Then, if you want to, you can move on to your templates and pages.

Okay, these are things that draw from all of the other little components and all your guidelines and they create templates of pages that you would use in your product.

Now, the last one is mock ups.

And this is where you're actually building things for your product.

And with the mock ups, I think it's important to note that every single company is different, okay?

You're not going to always have the same file system for every single company.

Me personally, okay, so I would have all different folders for all my projects, and then within those I'd have files, with the name of the ticket number, alright, because we use Jira, but that's not going to work for everyone.

It's important to note that, you might do it by platform split.

You might have iOS, Android, and, or your web, okay, you might have different folders for each of those.

Or if you're an agile environment, you might have your squad as folders.

Each to their own, there's no hard and fast rule, but as long as your company and all of your people inside know exactly what the structure is.

That's the important thing.

Alright, so a great design system, like I've mentioned, they all have documentation for every file, mock up, component, etc.

Now I've got on the screen just half of the documentation, or not even half of, for the buttons.

I've just, this is something that I've just whipped up as such.

So without the documentation, design components are like Lego bricks without instructions.

So going on the Lego theme here guys, with all of the people out there advertising their Lego.

So think about it, if I was to give every single one of you a Lego to build, and show you the end result but, not really give you the instructions.

How are you going to get there?

Like every single person, it's going to look different in the end.

And that kind of is what happens if you give someone a component, but, they don't know how to use it.

Okay?

Everything's going to look different.

So you can't build a product without knowing how to use the design system.

It's also really helpful when you're onboarding new team members as well.

Because then you don't have to worry about explaining every little thing to them.

And also, I think handing over to developers, so from designers to developers, this is also a really crucial point where you have the documentation.

So for components, it's probably a good idea to have a breakdown of all of the different variants.

All of the different states, so you're enabled, disabled, etc.

Also things like I've got up here, the spacing, okay?

Showing the padding and the margins, etc.

And that's really helpful for developers as well.

This documentation, it can be housed inside your design tool, or it could be external.

Somewhere like Confluence or Storybook, or wherever your company wants to store it.

But as long as everyone knows where it's kept, and they have access to it, that's all you need to worry about.

Now, I get really excited about this next one.

Spatial systems.

Okay, I'm a bit of a pixel princess is what they call me.

Okay, so I could tell you if something is two pixels off.

And the developers always hate me for this.

I don't blame them, it's really annoying, at the end, it produces something really beautiful.

Designers and developers, they make spatial decisions every day.

So the height of a button, the space between two different components, they're all spatial decisions.

Now, according to Elliot Dahl, in his article, Spaces, Space, Grids and Layouts.

A spatial system is a set of rules for how you measure, size, and space your UI elements.

Alright, so that's what it is.

Now, I wouldn't blame you.

Some people think, okay, a spatial system, is that a grid?

And like a grid is, a user space, but it's not a spatial system in itself, okay?

Of course, this is something that can greatly affect the consistency and also the efficiency of your design system.

Maybe if you're in an Agile environment, for example, where you only have enough time to produce maybe some sketches or some low fidelity wireframes to pass over to your developers.

This happens a lot, alright, because you don't have enough time to produce those high fidelity things.

Makes sense.

And you know what, you shouldn't actually need to produce the high fidelity things if you've got all of the documentation behind and your spatial system.

Okay?

Because then they know exactly what to do.

If they didn't have the documentation behind them, it's probably going to look a little like something on the left.

Alright?

They have no idea where to place things.

But if it's It does have all the spatial system behind them.

You're going to look more like something on the right.

Now my personal favorite is the 8 point grid, okay?

This is where, sorry, this is where everything is spaced and sized with multiples of 8, okay?

And same, you've got like a 5 point grid.

You might even use something like a 12 column grid.

Which is back to the old school days of your websites, right?

You might've seen that before.

Or even Flexbox, which is based off CSS.

Okay.

So there's a whole heap of different, spatial systems that you can use.

All right, next up, we've got color.

Okay.

And.

Now, I, when people ask what I do for a living, I joke that I just look at pretty colours all day.

Because it sounds cool, right?

You're looking at pretty colours and you're deciding which ones come and go.

Realistically though, colour palettes are the hardest thing you can do as a designer.

In my personal opinion.

I've spent weeks to months on just one color palette, okay?

Because you need to find that exact color, that exact hex code that you need.

And especially when you bring accessibility into the mix, and then theming, that's when it gets tricky.

So this is just a basis for what you can probably achieve in a short amount of time.

Choose a primary color or primary, secondary, and tertiary, that's probably going to be your brand colors.

Then you've got your functional colors.

Okay, so your information colors, your warnings, your errors, your successes.

And with your primary and your functional colors, you're probably also going to want to do an extended color palette.

So you can see underneath the ones that I've got up here.

So that's your tints and your shades of those primary ones because let's just face it, you can never have enough of those colors.

Then you've got your decorative colors, which just add a little bit of pop to your design system, to your product, and then your neutral colors, which is going to be a majority of your user interface, right?

You wouldn't think it, but everything from black to white and everything in between, those are your backgrounds, that's your text, those are your borders, your dividers, etc.

It takes up a lot of space.

Next up, we've got our icons.

And these help us navigate, and best of all, they're actually language independent.

Which is pretty cool, right?

So all over the world, all different languages, people are going to understand similar icons.

You've got your semantic icons, so your errors again, your successes.

You've got your actionable icons that you're actually going to be interacting with, so your close buttons, your edits, your arrows of all different shapes and sizes for your drop downs, your navigation, etc.

Then you've got your informational icons and they help out with the text, they pair up with text and help it out a little bit for the user.

And then you've got your decorative icons.

And similar to the decorative colors, just to add a little bit of fun to your product.

If you were to take them off the page, nothing would really be affected.

Then we've got typography.

Okay, so typography, it's a little bit of a tricky one.

Okay, if you're a beginner designer, I would recommend sticking to just one typeface.

And then just using, the different weights, so you can see here we've got black to regular, that's classified as your different weights for the typography, so you could probably help, have that hierarchy for the headings, just by using the different weights.

So maybe some bolder ones for the headings and some more me regular and medium for the base kind of paragraphs and stuff like that.

So with typography, play around with it, you can incorporate different typefaces if you want, that's really up to you.

And it's probably something that you want to go, you're going to want to talk to your marketing teams about because maybe they want to have a bit of consistency with how they're marketing your product.

All right.

And here is one called Atomic Design.

So this is now where we're actually getting to the building stage of the design system of those components.

Okay.

And again, this is Brad Frost.

He must be pretty good.

Cause I've already name dropped him twice, right?

So this is on his book, Atomic Design.

And this basically explains how to break down those components down to all the way down to little atoms.

Okay?

Atoms, molecules, organisms, templates and pages.

So it really is about breaking down those components, and yeah.

I'll give you a little example.

Down the bottom row, let's pretend we're making a contact card, okay?

So you've got an avatar of the person, you've got some text information about them, maybe their phone number.

Then you've got the card itself that's housed in.

So those are the atoms, those three things that I just mentioned.

The molecules, that's then when you bring those all together to make that component.

Then you've got the organisms, so maybe you have multiple contact cards that you want to display together.

Then you move up to templates, and this is going to be an example of what it actually looks like if you were to house them on a page.

And then we've got the pages themselves, okay?

So maybe you have a contact us on your product, a contact us page, and that then you have an example of how it kind of streamlines, how it goes from all the way down to atoms, all the way up to pages.

So once you've done your interface inventory, if you already have a product, okay, so if you already have a design system or you already have a product, you've done that interface inventory and you can actually pull then and see what kind of components that you want to put into your design system.

Now if you don't already have one, heaps of resources out there for you, but here's just a list of kind of the base components that you might want within a design system.

Okay, your avatars, your accordions, your banners, etc.

But realistically, it's all about what your product needs.

Okay, so have a look at your product and see what they need, what kind of components is going to build up that product.

So today we've talked about your collaborators.

Talked about who the owners are of your design system, what its benefits are, when you should build one, what kind of research you might need.

And trust me, that was just a little tiny drop in a massive lake because so much research just needs to be involved.

Talked about the planning and again, there's so much more planning that you could do and of course the building.

I only showed you just the beginning.

This is only a 30 minute talk.

I wish I could talk for hours, but I can't so thank you guys so much.