Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time. In this episode, we will walk you through the basics of building all the pieces of an Atomic Design Language, how to roll it out to your team or company, and scale it in your organization.
SHOW NOTES:
http://thecrazy1.com/episode-25-digital-design-what-are-atomic-design-systems-and-why-are-they-the-future/
FOLLOW THE CRAZY ONE:
Twitter, Instagram, LinkedIn, Facebook
Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time. In this episode, we will walk you through the basics of building all the pieces of an Atomic Design Language, how to roll it out to your team or company, and scale it in your organization.
SHOW NOTES:
http://thecrazy1.com/episode-25-digital-design-what-are-atomic-design-systems-and-why-are-they-the-future/
FOLLOW THE CRAZY ONE:
Twitter, Instagram, LinkedIn, Facebook
What's going on everybody, and welcome into the 25th episode of The Crazy One podcast. As always, I'm your host, Stephen Gates. And this is the show where we talk about creativity, leadership design, and a whole host of other things that matter to creative people. So today, we're gonna let our inner design nerd flag fly a little bit. For any of you who have followed my work for any period of time, you know that the work that I'm probably most known for is the work that I do in digital. And digital is an interesting thing to design for. Because over the past five or 10 years, we've seen an absolute explosion in what designing for digital means. It's a whole host of new form factors, new devices, new challenges and a whole bunch of things that's really changing the industry. Well, that creates a whole bunch of challenges for those of us who then need to go and design for it. And so there's a new concept that's come out in the last probably a year or two and is gaining popularity that I want to talk about called a Atomic design systems. And we're going to talk about what those are, why they're important and how you can create your own. But as always, before we jump into the show, there are two quick things I wanted to cover off on. One is if you haven't had a chance yet, head over to The Crazy One podcast Facebook page, give that a like, this is where we're building the community. It was one of those things where I really felt like, it wasn't maybe the smartest idea to have a whole bunch of kind of one on one email conversations. So let's build a community where everybody can benefit from what we're talking about. And the other thing I'd say to do is, as we head into 2017, I have a whole roster of new upcoming talks and workshops that I've got all over the United States that are coming up through at least the first half of 2017. So head over to my site, take a look at that and it'd be great to be able to see some of you guys out there in person. But on with the show. Atomic design systems are an interesting and kind of emerging new trend in digital design, but they can be tricky. They can be A little bit interesting to be able to build, they can be interesting to deploy, because it's just a different way of approaching design. So let's talk about five different things. today. We're going to start by talking about what exactly is atomic design? Just what does this mean? Where does this term come from? Just what the hell is it? We're gonna talk a little bit about why is it something that you actually need? Why is it something that's worth building? We'll look at some of the common mistakes that I found in building these systems just so hopefully, you can't repeat them. Well then go through and look at what are the five different parts, the five different layers that make up an atomic design system. And then finally, I want to share some of the things that I've learned and actually deploying these systems because that part of getting adoption for any sort of a system like this can be a little bit trickier than you think. So that's the agenda for today. But let's jump in and just look at honestly what the hell is atomic design and why is this something thing that I think that you need to be paying attention to or something you need to be doing? Well, the challenges is that as of, I don't know, what, three, four or five years ago, depending on how much you're pushing your design, the concept of pixel perfect design, that we're going to pick one particular screen width, and that's what we're gonna design to. And then everything we do is going to be in this nice pixel perfect fixed width sort of design. Well, those days are long gone. And I still see a lot of designers, a lot of companies, a lot of brands struggling to figure out where do we go from here? The reality around design today is that there are really probably four factors at play here that I think that we need to think about, or at the very least, we need to recognize. The first is that there is absolutely an increased focus on design. I would argue probably more now than ever before, maybe since even as back is like the Industrial Revolution. So just simply the expectations of what design brings to the table. Just in in terms of beauty, because beauties, beauty is easy, like it's not hard to make something that's pretty and I get very frustrated with the number of people who just want to focus on just pretty on this sort of like Pinterest worthy internet famous sort of approach to design, that the expectations for what we're doing are actually a lot higher than that. They need to be able to perform from a brand standpoint, they need to be able to perform from a revenue standpoint, from a sustainability standpoint that we aren't reinventing what it is we're building every few years. And because of this explosion in form factors, because of this pressure on design, we're starting to see just new dynamics and the way things are created in my world, it really has become a lot more about not only the internal teams that I build the client side teams, but then how those teams work with the external agencies and and just this kind of symbiosis between the two because there has been this paradigm shift over the past probably five to 10 years. We're coming are bringing more of this creativity in house. So how do we deal with this dynamic? what I said before about the fact that we're creating for a multitude of different platforms, it used to just be that web was enough. Well, now not even web is enough, because web now needs to be responsive. There's mobile apps, there's tablet apps, there's social media, there's emerging media, there's wearables, there's on and on and on all these different kind of things that we need to be able to figure out. How do we design for and how do we create consistency across all these different screen sizes across all these different form factors, but do it without losing creativity. And that would be one of the key things we're going to talk about today. And finally, the design systems that I do see that are out there, the ones that I've gone, and I've worked with or the ones that I've evaluated for people. The problem is that those systems just have some really fundamental flaws in them. Either that there are too few constraints and that the brand loses Brand consistency, because all of a sudden you go from section to section and the button color has changed the photography style changes the way the interactions are done change, or there are too many constraints that and I've said this before that too often I see excess process being the result of stupidity or lack of communication. And in this case, I think it holds true as well, where you can tell that there are agencies that didn't follow the rules, there are designers that didn't follow the rules. So the overreaction to that were these systems that became just impossible to work with because they were just so insanely complex. So how do we get over this? How do you maintain a brand? And how do you maintain that sort of experiential design consistency without losing creativity? So enter atomic design systems, and I'm not going to even come close to taking credit for coming up with the term or with this idea. There was a gentleman by the name of Brad frost, who wrote some really good articles. also wrote a book about atomic design systems. And he's the one who really deserves the credit for being able to kind of give shape to this trend that was out there and design. And for those of you who want to take a look at his book, or take a look at some of his articles, I'm gonna put the links to all that stuff in the show notes as usual. So you can just head over to the site and pick up that stuff there. But what Brad really did was he just sat down and said, Okay, look, how do we find creativity and consistency. And in the process of doing that, he really kept coming back to chemistry. And it may seem to some people like that may be an odd correlation to make. But for me is somebody that looks to cooking and street art and tattooing and a whole bunch of other things to find his inspiration. To me, it actually makes sense to look at other industries or other things like that to find inspiration. But Brad really looked at chemistry for a very simple reason that I think it makes a lot of sense. And really that what he was thinking about is that in chemistry, all matter all fields physical matter is comprised of atoms. And those are really just like these atomic units that bond together to form molecules, which in turn combine to form more complex, more complex organisms, ultimately creating all the matter that there is in the universe. So it's this, basically a scalable system that happens, and how he felt like that actually made a lot of sense. Because it's one of these things where I think if you think about it, it may be a new term to people. But the concept of building these kind of visual systems where you can take pieces and combine them to create increasing complexity, well, that's really just the visual language for any brand that you work on. It's really not a terribly new concept to us. It's just the level of complexity may be new, the level of the way that we need to deploy this may be new, but the core idea itself really isn't that new. But we're gonna get to actually the five steps Hear in a minute. But I also just want to make clear what this isn't. And when I think that this isn't is this is this isn't just a set of templates. This is a real design system that starts with the very base elements and then lets you combine those in increasing complexity that I've seen some people mistakenly call atomic design, just a series of templates. And so let's debunk that right here. But we'll also kind of talk about the pros and cons of just the template approach here in a minute. And just so you know, this is something I actually really do have tangible experience with one of the first things that I did whenever I got to city was to look across all of their digital experiences and to see that they were having these challenges. their existing systems were struggling to give the teams that creativity they needed, that the experiences when you look at them were very inconsistent for a lot of different reasons. So over the past year, plus I said about really, really leading a team of some really incredible people to create what we call the city DDL It's called the DDL, because I guess everything in corporate America has to be a three letter acronym. But it stands for digital design language. And it really was. For us. It's our atomic design system so that the insights that are here, the way of developing this are actually drawn from my experiences over the past year, building this at a very large scale. But I also just want to talk about the fact that these systems don't just have to be for huge brands, they don't just have to be for big teams. Even if you're just two or three people, even if you're just building a singular app, the challenges of design consistency while maintaining creativity are still going to be there. So don't fall into the trap of thinking that this is something that's only for these big Leviathan brands that it it's something that really isn't for you. Where do you start? And I think that with most things that I design, the place where I start rarely has anything to do with the way the final product is actually going to look. For me it still comes back to that base. Core thought that great design is a visual expression of great thinking. And so if I'm going to design a system, if I'm going to design a design system, I think that the first thing that you need to do is you need to take a little bit of time to sit down and set some standards, you need to be clear about what does your design system need to accomplish? What are the standards that you're going to hold it to? Because I think if you don't do that upfront, just like with any design, without those guardrails, the solution is going to wander, you're gonna be all over the place, it's gonna be really hard to find a way of defining is it successful or not? Is it really working or not? Because you need to know, what are some of the things that this needs to answer for. And so I'll just I'll give you some examples that hopefully you can learn from and you can make your own. So some standards that if I was going to go out and design one of these more modern design systems, some of the things that I would look for, would be I would want a design system that's mobile first. that it works across apps. It works across responsive design that we see more and more traffic we just saw on Black Friday and Cyber Monday that the majority of traffic is now coming from mobile devices. So because of that trend, we need to be mobile. First, we need to focus in on that, that there needs to be consistency across the design system. It needs to have a consistent look and feel that it needs to look as one brand one experience that the challenge that so often happens is that from a business perspective, we tend to look business out from a design perspective. We always want to create something new and we want that challenge. First, was we talked about in many episodes in the past, that's not the right way to approach things. You need to have more of a consumer centric customer first sort of approach to things. So I need a consistent look and feel I need a consistent experience so that consumers can come in and have one experience with this brand. I need the system to be form factor agnostic that we're designing For a ton of different screen sizes, so I need something that can work on something as small as a smartwatch or a wearable, I needed to work through mobile apps, tablet apps, I needed to work on websites, maybe even I needed to work on television screens or billboards or online advertising. But I think, think about what are the form factors that you want to target so that you know if it's gonna work or not, that so often we need solutions in this day and age that are global, that this can't just be a North American perspective on design. And this could be as simple as something as a date picker, a currency display, a telephone number, these are all things that have very different conventions whenever you work with different people all around the world. So should we think about that should we think about things like language, as in with most of my designs, I generally like to design in English, German and Japanese, because German and Japanese usually are the two that will break design systems the most easily German because of just the sheer length of the language will suddenly force your system into heaven. To accommodate for a lot more text than maybe you were planning to be there in the past Japanese again, just because the way that the characters break is vastly different than a romance based language. And then finally, I think there's just some of the basic evolution of design that I think a lot of designers aren't thinking about. But increasingly, if you don't, your legal team is going to force you to think about them. And those are things like being a DEA compliance. So the Americans with Disabilities Act, there are certain things that you need to do. There's certain type sizes, there's certain level of contrast in your design that has to happen, so that people who have visual impairments so that people who have hearing impairments for people who need to use, visual readers can still really make your site work. And there's an entire art and science that surrounds this, but it's something that you really need to think about. Because if you're going to introduce a base design language, it has to be able to account for these sort of things. Those are some of the things I would tell you to think about. What are the standards, what are the things that I want it to accomplish? And that how am I going to go through and actually make that happen. I've looked at over the years having spent at this point in my career equal times on the agency side and equal time on the client side, I've looked at a lot of brand systems, I've looked at a lot of design systems. I've looked at a lot of digital design systems working with the different teams that I have at different companies. And through those I see probably six, what I feel like are the most common mistakes. And I wanted to share those just because of these are things that you're currently doing. If these are things that you're thinking about doing. I would beg you not to, because I think that these are some of the things that can kill or at least hampers some really great thinking they can really get in the way of deploying these systems and making it something that is really going to be useful. So the six most common mistakes that I've seen are, the first one is that whenever these design systems get rolled out, that the design team that builds them just simply sends them off into the world. And once they do There is very little communication, or there's no interaction from the design team that built them, they go out, they build them, and they just launched them into the world, and then only whenever something is really broken only when something gets outdated, only when there's a driver for the business, so they then come back and want to interact with it again, only then do they maintain it. And I think that this leads to the second one, which is that in some cases there, there is just simply no governance in place, which is the other extension of this kind of communication problem. Because governance really makes up a few different things. I think, on the one hand, it does just what you would think it does from hearing that word is that there is nobody who just makes sure that the system is implemented the right way. Because that's the problem is you need somebody who can at the very least answer questions Who can look at what's going on, who can make sure that the design system is being applied consistently, and that you need some level of governance To do that, but you also need somebody from a governance perspective who can keep an eye on? How does the system need to grow? How does it need to evolve? How do we need to change it and grow it? And so it's not just this sort of police state on design, but it really is coming in and saying, Okay, this is a living, breathing thing. How are we going to maintain this? How are we going to grow it? The other thing, and we'll talk about this in a little bit more detail later is that there are just simply too many versions of the design language, that there'll be a one.oh, one dot one, one dot, one dot phi, one dot 12, one dot, whatever. And all of these versions start to become incredibly confusing, because all of a sudden, you'll see that, well, maybe the websites on one dot five, the app is on one dot eight, the tablet is on one dot 12. Well, how do you reconcile that because now all of a sudden, the very thing that we said that we wanted to do that the whole purpose of creating consistency is going out the window because we're starting to fracture All of these different things because of these different versions, that the design systems in some cases, they aren't sustainable, or they aren't expandable, that we can't add to them, that they're very inflexible. And that that is a real problem. Because I think that that really is one of the challenges that is that we have to sustain it, we have to maintain it, it has to grow, it has to evolve. And that's really a concept that I latch on to whenever I build these is that these are things that they're meant to change. They're meant to evolve. You have to be able to build that into them, but the ones that don't have enough creative flexibility, those are the ones that really struggle. And finally, the mistake that I see is that whenever all this work is done, and there are some of these that I've seen that are quite extensive. They are launched in these absolute tomes, these monsterous PDF, what amount of free time is it going to take to read 400 pages, 600 pages. It's just idiotic Nobody's going to be able to engage with it, nobody's going to be an expert in it. Because you're making consuming it so insanely hard that nobody's going to do anything with it. Those are just some of the common mistakes as we head into this that I would ask, beg, plead you not to repeat. Okay, how do we actually make one of these systems, what needs to go into it? What are the parts that go into an atomic design system, and there are just five of them. And if we can just run through these really quickly, they're very easy to kind of wrap your head around. And if you want to, if you feel like calling it atomic design is too nerdy, if you feel like it's gonna wear it out to your clients, you can name them other things. There's a host of other things you can easily think of. But it's the core concept that really holds true here. But for true atomic design, there are five parts that are atoms, molecules, organisms, templates, and pages. And each of these really builds on the next let's start with the base building block. Let's start with that. Adam, and atoms are just what I said, these are the basic building blocks of all matter. Whenever we apply this to this concept of digital design, they can be things like a form label, or an input a button, even a color or a font, even down to in some cases, and we'll talk about this in a bit more detail, invisible things like animation. But these are really what are the smallest definable elements of an interface? What is the most basic building block. So from those, we can take the molecules and they start to get a little bit more interesting and we get into molecules, they start to get a little bit more tangible because with a molecule, you start to combine atoms together. And molecules are just groups of atoms that are bonded together and are the smallest fundamental unit of a compound. So again, going back to reference chemistry or making go have a high school flashback now, that's really what that is. So let's use a 10 example, if we have a form label or an input or button, they aren't too useful just by themselves. But if we combine them together, now we have that form label and input in a button, well, then that suddenly creates a form, and they can actually do something together. So it's taking these individual set of parts and combining them together. An organism then is the next level of complexity, because molecules give us some of the building blocks to work with. And we can combine those together to conform to form organisms. And organisms are just groups of molecules that are joined together to form a relatively complex distinct section of an interface. And here again, let's talk about a tangible example. So you know what the hell that means. We looked at something that would be like a masthead organism. This might consist of a bunch of kind of diverse components. We could have a logo, primary navigation, a search form, a list of social media channels, those are all different things that we could go through. And we could take those different molecules, and each one of those might be a molecule that we've created and combine those together into an organism. But it's this building up from molecules to organisms that really encourages creating these standalone, portable, reusable components. Because this is the challenge as designers, and I think we'll talk about this more in a minute. But it's this struggle, where I think we feel like every single time we have to create something new, we only demonstrate our, our deep value, if we're creating a new interface, if we're creating this sort of new way of doing things, but there are some times we have to just look at the bigger picture, that for brand consistency, we can't create a new interface every time that for a consistent user experience. Do we really need to reinvent something like a product listing every time Do we really need to reinvent an address entry field. These are just some base components that we can just use over and over again, and there's still plenty of other opportunities to build brand there's still plenty of other options. For us to go out, and to create and design these really kind of beautiful things, but making atoms, molecules and organisms, it gives you this system of increasing complexity, so that you can get consistency where you need it. But you can still get creative freedom. The other thing is that if you're in a leadership position, the thing that this scalable system allows you to do, is whenever you work with really talented designers, you can just give them the atoms, give them the individual pieces and let them go crazy. But if you're working with maybe an agency that's not quite that talented, maybe an internal designer who's not quite that talented, the ability to have the molecules and organisms gives them the ability to still design things to still create, but it pulls a little bit of that creative freedom away from them. But it still gives you the ability to know that what's being created is going to be what it is that you need. So it creates this basically a sliding scale so that the experts can go work with the atoms and the novices can just go work with the organisms. It still lets everybody in To the 10th. It lets everybody come in and be able to work with this stuff, which I think is really important. The next stage of this, the fourth stage is when we start to actually talk about templates. And templates, obviously, is kind of where we lose the chemistry analogy. And it's one of those things where we start to really kind of talk more about how do we start to translate this into the actual design work that we need to do. Now, templates consists mostly of groups of organisms that are stitched together to form pages. And this is really the place where we start to see the design come together. And we start to see things really in action. And sometimes it's this forest for the trees dance, that can be a little bit challenging. With templates, we start to walk away from the pieces and we start to get something that's more concrete, something that gives us more context, all these sort of abstract ideas, because for a lot of non designers, the atoms the molecules and the organisms is this sort of abstract thing because most people they want and they need context, they need to understand kind of how things come together and where the templates is where we start to see this final design coming into place. The only thing that I would say for this is that there are real pros and cons to templates, this is probably the one stage of the system that I go the lightest on. Because for me, I kind of feel like if you're going to get into templates, and I think that they absolutely have their place, I think that having some of them off the shelf is not a bad idea, the ability so that tech doesn't have to constantly create new things. The just the sheer fact that there may be some interactions that are fine, if those are templatized. Those are good things. But you have to also not fall down the rabbit hole of just creating templates for everything. Because for me, one of two things is going to happen. One is going to be that your design team will turn into a template factory, that there will never be an end to the number of templates that you need to create. So that's just such a hard thing to do. And the difference between a design and a template for me is also the The level of supporting documentation, the level of level of Sustainability, and a lot of those other things that is going to chew up a huge amount of your time. The other reason why I struggle with templates is because I've seen too many clients. And I've seen too many companies that quickly start to use the templates as an excuse. Because what they'll do is they'll go into your template library, they'll look around for what they want to do. And in fairly short order, they're going to declare that there is no template for what it is that they're doing. There's nothing that fits their needs. So well, that gives them the the license and the ability to just go off and do whatever it is that they want. They can break whatever rules because, well, like you said, there are templates, there's not a template for us, so we're gonna go do our own thing. And that is a maddening process. It is an incredibly frustrating process to have to go through to kind of fight this stuff back. I would just simply say to think about your culture to think about how and where to use templates and what are the places where it really starts to undercut the value and really the the perceived notion Have what your design team is, if all that they're seeing is doing or being the people that just go through and create templates. The last and final piece of this is pages. And pages really, in a lot of cases are these sort of specific instances of templates. This is the place where kind of the placeholder content that we have the lorem ipsum, this is gonna get replaced with real representative content that it gives us an accurate depiction of what the user is ultimately going to see this is essentially design. This is the ultimate expression of kind of what comes out of this. And here again, I think, if you're using a mobile app, if you're doing something on wearables, maybe pages isn't the right way to describe this. It's a very web centric term. And that there is a decent part of this in some of the terminology whenever you go out and read it that very much still focuses on web. And I think that, you know, these systems can evolve to become something more than just that. But the pages are really the highest level of fidelity because they're the most tangible, and it's typically where I think most people spend the most of their time and it's what The reviews and things like that revolve around. And so the one thing that I will tell you with pages, is that just understand what is the page as an artifact of design? And then what is the system? Because here again, I'll see a lot of people that will suddenly blame the design system for what is really a mistaken design on the page. That In my case, they'll say, Oh, well, the city DDL, well, that's not letting us do something. It's like, Okay, well, how does that ever gonna make any sense because if you can deconstruct something all the way down to an atom, you have all the pieces you need to do whatever you want. It may just be the implementation of it isn't allowing you to do what it is that you want to do it maybe there's a business rule, but just understand how do you separate the page from the system and not let those two get kind of muddied up. Those are the five pieces that we have. Those are the five base building blocks. And so once you go through and you create these, really the place that I would tell you to do is to start with to probably start depending on how your team likes to work on either end of the system. If you have Existing pages, if you have an existing site, you can take those and deconstruct those back to atoms to be able to start the basis of your design system. If you're doing it from scratch, then I would encourage you to really start from the atom level. And then to be able to build up obviously, there's this interplay that always has to happen between the pieces and the whole. And I think depending on the complexity of your system, depending on the way your team likes to work, it's going to change how you want to kind of attack building this problem. Once you do it. There's some other kind of recommendations that I would really kind of go through and really encourage you to do before you launch it before you put it out into the world. And even once you do just some things to be able to think about. The first is that IV you absolutely have to spend probably more time than you would think pressure testing your system before you launch it. And I think my pressure testing it. There's, I mean, with my work, I guess I always think about how can I break my ideas? How can I break my design? How do I find the weaknesses? Isn't it? How do I find the things that aren't working? And how do I go out and fix those? And I think that for me is pressure testing. Because I want to find those things. I want that level of, honestly, almost ruthlessness to happen on my team before it goes out into the world. So pressure testing, I think, is doing a bunch of different things. I think the first one is while you're building this system, don't be afraid of doing research, put it in front of people as often as you can, as quickly as you can try to break it, try to find where the faults are, find what's working fine, what's not working. But this is the time to really kind of embrace that research process to be able to look at the individual elements for ADA compliance, to create test pages to see if the system is really holding together but put a research budget just against the system. And to be able to kind of look at that. It's like I said, go through and validate the ADA experience because that is a not insignificant process. And I think that the challenge and the thing that you don't want to have happen is that you launch it people start to adopt it. They start to code it, they start to launch things in it. Well, then all of a sudden, you realize that there's some big flaw, you realize that it's not ADA compliant, you realize that it actually isn't working the way that you said it would. And then you have to go out and make a bunch of changes with the problem is that you kind of only get the first shot to make a first impression. So if that impression is that, well, this system actually wasn't as well thought out, as we thought it was that there are some kind of big inherent problems with it. They're going to ask people to go back and make changes around, well, then people are naturally just going to start to question, what else is broken? What else doesn't work? Why should I really invest in this? Are they really thinking this out as well as they should have? And that doubt can be just an absolute killer and absolute destroyer? what it is you're trying to do? Make some test pages, do some research, look at these sort of things. I mean, the other thing I'll tell you to do is once you feel like it's starting to be in a viable place, give it to a team that's never worked with it before and see what they do look at the work that they do, what are the questions that they have, but really do Try to break it before you give it to the world really try to make sure that it works, and to do these sort of things. And then once you've done that, once you've gone through and you felt like you really pressure tested it, that you're seeing good results coming back that people understand that in deployed and there aren't these major sort of flaws in it? Well, then it comes time to roll it out, then it comes time to deploy it. And there, I think there is just some tricks, there's some tips and there's some traps that I would kind of want to share with you guys. I think that the first one for me whenever you deploy it, is how do I make this as simple as possible for people to pick up and use? How do I make the antithesis, the opposite of that four to 600 page PDF? How do I make this something where, as a designer, I'm going to come into this system cold and when I just want to start? How can I start? How can I just get in and start being able to work with it and not have to go through this massive onboarding experience. And this is something where I honestly stole this idea from Google and I'm very open say that because one of the things that I think they did really well was when you look at the way that they rolled out the material design language, that is the design language that drives everything they do on Android, they did a really good job of creating what they call a sticker sheet, which is basically you can go in and get a file, there's as in Photoshop or sketch, but it's basically all the base components of Android that you would need to work in design with just in one document. And for me, I went through their website, and it is very complicated for me like it is fantastic. It is an incredible level of documentation. I think it's probably like the gold standard of what you want to aspire to. But it's the gold standard of the point where almost becomes inhibiting just because there's so much of it. But the sticker sheet makes it so simple. It makes it something where I could just open this document and start working. So I would encourage you to make a similar document for your design language. How do you make your sticker sheet? How do we make this one file that has everything you'd want in one place? It has all the buttons are already built all the type sizes already done into these different type styles so that they're completely reusable that we have the atoms, the organisms, the molecules all laid out right there. So I can just start to like a grocery store, go in and start picking what I need off the shelves to build my recipe, my dish. But I think that that, for me is one of the biggest kind of tricks that I've learned that I think works incredibly well because it just makes it so easy to work with a design system that you can just pick it up and start working without this huge onboarding. And that really gives the designer is really just the ability to focus on creating the best experience. And this is a place where if I'm being honest, you may find some resistance, because it's like I said, as a creative community, we like new, we often are rewarded for new. That new is what we seem to derive value from and it was what goes into our portfolios. And so some designers will struggle in working this way because they feel like we're taking some of the creativity away from them. That They aren't really creating these elements every time. And that's something that they really miss. And that, you know, as a result that maybe they aren't as creative as they used to be. And I just, I guess I take issue with that. Because for me, at the end of the day, it's the experience that counts. Yes, the design is absolutely critical to this. But it's the way that you move somebody through an experience. It's the story you tell, it's the simplicity that you bring to a comp, formerly complex process. That that's the beauty that that's where the design of this really comes from. And it really lets I think, focus on what is the best possible experience. And I guess I would also argue that because of the fact that the atoms are still there, you can take these pieces and just simply combine them in any way you want. That it's not any different than whenever you worked with a brand standard, that that defined a set of typography that designed the colors that you worked with it defined all of these things for you. It was just the act of you creating the shape of the button. Placing the type into it. It's that bridge. That seems to be where the problem comes. But I just don't think that I, for me, I find it much more liberating, because it lets me just focus on creating the experience on creating something that really is fantastic and focusing on the idea and not have to focus on the idea and try to build this system all at the same time. The other big thing that I think that is absolutely critical is that to successfully launch an atomic design system, I really think that it comes down to probably three things that will make or break the system. And I think those three things are communication, communication, communication, the way that you communicate the system, the way that you maintain it the way that you continue to work with people and give them a voice into the system so that it doesn't seem like it's just this police state, that if something is working for the business, if it is working for designers tell us, but also if it isn't, tell us. Let's have a conversation about Well, that was actually a deliberate decision that we made and we're gonna stick with that, or you know what that actually is a missing piece of the system. And so because of that, that is something that we're gonna go back and look at it, maybe we want to change, maybe we want to add to that. But communication is incredibly important. And I think there's a few kind of key ways that you can make this much easier on yourself. The first one is to replace those Leviathan PDFs with a website, because a website just inherently makes it feel like more of a living document. And this website really should be the documentation. It should be the Bible, from everybody from the most advanced designer, to the most basic designer, from a developer to a business partner, something where I can come in and I can understand the approach to how the system was made, I can understand the standards that we established that we're going after that I can see and interact with the system. And I can even give developers the code snippets so that they can pick up this and they can start working with it. That if the system is responsive, and I will say that I do think that they should be the website. responses. So I can come in and I can see, as the system goes down through the different breakpoints, how does that actually work? Or maybe that we actually are doing the more modern approach on this, and we're doing media queries, and that the concept of breakpoints isn't something we're doing anymore. So let's explain what that is. But this is the one stop shop, the 24 hour, 365 day a year place where I can come and get the latest and greatest of everything that's going on. The other thing and I know this sounds like the most corporate thing on the face of the earth. But the other thing that I would probably encourage you to do as corny as it might sound, is start a newsletter. Because you need some sort of regular proactive communication that updates everybody who uses your design system about what's going on. Because it just is one of those things where as much as we would love to believe that everybody is going back every week, every month, every some regular interval to check on the website and see what's new, that may be overly optimistic. And so it's one of these things where Okay, How do we proactively communicate What's going on? And to be able to get that out there so people understand what's going on. And the last piece of this that I would really encourage is that there is simply no substitute for doing roadshows that the best way to launch a system is to go and do a roadshow to explain the system to show the results and to answer any questions to literally just take the time with key sets of people to walk them through it. Or the other trick that I've done in the past is that sometimes these road shows can become a pretty big time draw to take one of them and record it. Record just the audio, record the video of it, just do something so that it's easily shareable. So if you don't want to be doing 20 of these road shows a week, maybe do the two that are the most important to the other 18 send the video and say, Look, here's a 20 minute video. I'd love for you guys to watch this. And then if you have any questions, you know what, let's jump on a quick phone call and I can answer those. But just think about how are you actually going to get out there and support it because that's the other problem. If you Aren't the spokesperson for it if you aren't the one who's passionately advocating for it, nobody else will. So past that, how do you maintain it? Because these need to be living systems, these need to be living documents. They can't just be something you launch it and forget it. So there's a few tricks that I would tell you for maintaining your design system. The first one is to develop a clear process for how to new items get into the system. Think about this as a backlog, if you're running agile, that what is the backlog? And that how do we make that backlog public? so that everybody sees what's coming up next? How do they know that we're responding to these challenges? That what we need to do then is we need to work with our business partners, our tech partners, to groom and to prioritize that backlog because different teams may have different needs, they may have suddenly a need for a component and they're on a two week sprint and we need to be able to get that to them to make the process clear of how do you get the stuff into the system, making it public of what it is that we're working on. And then what the priority is so that this doesn't get lost to confusion in the system isn't written off, because people just simply don't understand how is it evolving? And why isn't it meeting my needs. And so part of that really comes down to governance. governance, I think it sounds kind of like a dirty word or an overly bureaucratic sort of word for designers. But I think governance is really important. Because all the governance really means is that you have a team or you have people that are dedicated to maintaining the system. They're dedicated to answering questions, and that there's some form for them to be able to do that. So one of the things that my team does is that we hold meetings twice a month. And these are dedicated DDL meetings. And these are meant to be designed reviews. They're meant to be to answer questions and anybody and everybody is fully welcome to come to these. All of our agencies, all of our internal teams, anybody it is an open forum on how is it going, how are you deploying the system? How well is it working and what can we answer for you? Now, every two weeks might seem like a lot, but as you're just getting the system off the ground, that probably is about the right cadence. And I think you can decrease those meetings over time. But you need some forum, you need some support group for people to be able to come together and help answer these sorts of things, and a governance team that can help lead those so that there is just sort of one single point of truth for how do we need to be able to work with this stuff. And the last one, and we talked about this in the common problems a little bit is going to be versioning. How do you grow the system? How do you evolve it? And the thing that I would say is I just I think you need to think about how are you going to communicate additions to your design system? I would personally argue against versioning because I think that the whole point of a design system really is that it evolves and that if you build it right and if you do it right, and maybe this is a slightly naive way of looking at it, you shouldn't have to make any major big breaking changes that it should just simply be That there's a new tab controller that we need. There's a new header module that we need, there's a new, some sort of just addition to the system, and that those come up, and then we can just simply add on to the system, because versioning implies that there is a new version. Well, what it might actually be is that 99.5% of the system stayed exactly the same. Maybe we tweaked one little module waiting, maybe we just added a few other things on to the end of it. So versioning, though I think is also just bigger than the design piece of it. I think it's also thinking about whenever you actually build the system, when you work with your tech partners, what's the right way for them to be able to do it? Because Is it a pull model? Or is it a push model? Is it something where we build it and then it's up to all these other teams to be able to consume it and kind of put their stuff and make it up to date? Or is it a push model, where as we go through and we evolve the code just simply naturally gets rolled out across all these experiences. So any tweaks and evolutions just naturally show up so that everything's stays up to date. There are pros and cons to both. I think that the pool model, definitely make sure that you aren't breaking anything. But it also means that, you know, your ability to stay up to date is going to be much, much harder. And the push model really gives you the ability to stay up to date, it decreases the amount of overall work you need to do to stay in line. But it does mean that there is more work and there's more QA to make sure that when you push something out, you don't break your entire system. And then the last thing that I think we really need to talk about is the fact that a lot of what we've talked about and a lot of what I think is so often just the beginning part of creating an atomic design system really just focuses on visual consistency. Buttons are the same color type is the same size. modules and components really kind of look consistent across all these different things. Well, that gives us visual consistency. But we need to keep evolving and and the problem is there's a lot more challenges that are out there past that and I can do, I'm sure a whole nother show just on some of these things. But some of the things is Do you get past visual consistency that you need to start thinking about? You need to start thinking about things like interaction patterns. How does it not just look, but how does it behave? Whenever an alert comes up? What's the animation for that? What's the way that we handle, you know, error handling? What's the way that we handle the way that something loads? What's the load order of a page? A lot of these just individual things that are these interaction patterns that define the way it behaves? Not just the way it looks? Are there other things that we need to solve for this, we need to create different versions for branding? Do we need to start suddenly going beyond just the design and start looking at things like tone of voice, that it really becomes about? Okay, well, the content is a huge part of this as well. So how do we create a design system for copy? How do we create that tone and voice sort of translation knowledge if you've ever worked on global brands, but how do we create that for English or the language that we're working in? And the other thing that you need to start thinking about and this is something that I've recently deployed is the fact that there is an inherent problem that will be created for your information architects, whenever you start working with atomic design systems in the fact that some places I've seen will have these user experience architects pick up what is basically the design version of the system and create wireframes. With that, well, that creates two inherent problems. One is that all of a sudden, the role of the AI in the role of the designer suddenly comes slamming down together. And again, the designers are going to feel very threatened that their job is being taken away from them. Because the AI is maybe starting to dictate some of these design decisions. The other thing that you're going to do is you're going to start to run into a problem with your clients. Because what used to be wireframes, what used to be things that were much more clearly low fidelity, much more clearly things that were focused on just finding out the idea and the flow. And all of a sudden, they look much more like finished designs, and now all of a sudden they're being judged much more like finished designs. And so those critiques that used to be about the usability and some of the form factor and things like that suddenly are falling on Design comments. So the thing that I would encourage you to do, the thing that I've done is to also create a low res version of your design system just for wireframing. This could be something where it's just simply pulling out some of the colors, it could be making it so that things literally look more like wireframes. But just something where there is a wireframing version of this, that you have that lets you do some of these just explorations without it being judged as final design. And there's a whole host more of these, but it's like I said, once you start getting past visual consistency, and once your system starts getting to maturity, these are some of the things you're going to start to struggle with. Just to kind of do a quick recap, think about the standards that you want for your system, make sure that those are clear, that make sure you go through and you build the five parts of your design system that it is absolutely imperative that you have this escalating set of complexity that really lets this stuff kind of come to life to pressure test and pressure test and pressure test your ideas to make sure that it Something that you are breaking it before other people do that you aren't just being precious and thinking that it's beautiful and wonderful. And it'll be fine when it gets out there because others out there in the world will not be so kind. And then to deploy and maintain it to communicate what's going on with it, to make it a conversation, not just simply this big thing that comes down from the mountain on two stone tablets that it is a living document that people can work with. And I think if you do all of those things you really will see and like I said before, at any scale, I've seen this work for three person teams, and 300 person teams. But it is something that really does make your life much easier, and that the investment in it in the long term really gets you where you need to go. Because the reality is, is that digital is only going to get more complicated. We don't see the number of form factors slowing down we don't see the demands on these digital experiences slowing down anytime soon. If anything, there is the demand for how do we build this stuff and use it across more of these. So just kind of wake up to that reality wake up to it is a new way of designing and it is an evolution that we all have to go through. But it's one where if we do this, we keep control of that we keep control of our design. And all of a sudden, it isn't being driven only by data, all of a sudden, we aren't losing even more of this sort of design opinion that we all fight so hard to have. It's what I said is I just think you need to be able to spend some time and figure out how this can work for you. Hopefully, that helps. If you have any questions, like I said, head over to the Facebook page, feel free to put them up there. I'll get back to everybody really as quickly as I can. And I think it really is a good thing if everybody can participate in that conversation, just because then we all get better and get smarter for it. If you like the show, the only currency that I ever asked for is head over to iTunes, head over to Google Play head over to whatever your favorite platform is and leave a review. It makes a big difference. It gets more people to the show and it's the only currency like I said that'll ever ask for. We talked earlier about the show notes and if you're interested in those you can always head over to podcast dot Stephen Gates calm. Stephen has s t e p h e n gates calm We have all the other podcasts there we have the related articles, we've got the show notes, anything that ever comes up on this, if you ever want to find out more, that's the place to go and check it out. As always, the boys down and legal want me to remind you that everything I talked about here, they're my own views. They don't represent any of my current or former employers. It's just me out here ranting. And finally, I say it every time because I mean it every time but thank you for your time. I know that time is truly the only real luxury that we have. And I'm always incredibly appreciative that you want to spend any of it with me. So until next time, stay crazy.