Digital Product Design: Build a Flexible Design System That Lasts

1. Introduction: My name is Brad Frost, and I'm a web designer, speaker, author, and consultant based in Pittsburgh, Pennsylvania. And today's class is all about creating successful design systems, and introducing the atomic design methodology. A design system is the canonical story of how your organization designs and builds digital products. Design systems allow teams to launch higher quality work faster than ever before. Lots and lots of organizations are investing in that, which is great. But at the same time now that it's sort of it's own buzzword, you see lots and lots of teams going off in establishing buttons, and cards, and headers, and all sorts of other components in isolation. Then after the fact, they sort of plug them into their actual products only to find them fall on their face. Atomic design is a methodology that I created to help me and the teams I work with think about UI as a thoughtful set of interconnected parts. Over the last five years, atomic design has emerged as pretty solid wave for certainly my own projects, but also organizations across the world to help establish their designed systems and think about design systems in a more thoughtful connected way. This class is for designers and developers and really anyone involved in the success of digital products at an organization. After taking this class, you'll understand how to successfully kick off a design system initiative. You'll be armed with the methodology for thoughtfully creating a design systems components that can help you stand up your initial design system, as well as governance over time. So thanks for joining this class, and let's dive in. 2. What are Design Systems?: So, the first thing we're going to do is have a quick refresher of what exactly is a design system. This is covered in lots of places elsewhere but it's actually a hard thing to pin down exactly. What is a design system? The definition that I tend to use is that a design system is the canonical story of how your organization designs and builds digital products. I like to put this through the lens of a new hire. You hire a smart, talented person and they're inevitably going to ask so, how do we do things here? How do we design how? Do we develop? When you have a designed system, you could answer that question by directing them in the direction of the design system. You can say, "Here, here is the story of how we do things here, here's what design language we use, here's my code conventions we use, here's all the other things that help paint the picture for anyone designing and building digital products at the company. There's a lot of different ingredients to a design system and generally they take the shape of a couple of different things. There's the tangible artifacts of a design system. The actual UI components which are the bread and butter of a design system as well as design resources, icons, and things like that. But then there's also the overarching guidelines on how to use these artifacts. Think about it like Ikea furniture. You have the actual parts of the Ikea furniture that you dumped out onto the table and eventually assemble into the finished product. But without an instruction manual, it's going to be a tough go. So, you technically can do it with just a kit of parts, but at the same time, that instruction manual helps provide some context and guidance for how to thoughtfully put these things together to save your hair and your sanity. In which ingredients your design system includes is going to depend on what your organization, what your teams need in order to successfully design and build products. So, your design system might include things like design principles, design tokens, UX guidelines, writing guidelines, voice and tone guidelines, development guidelines, the actual coded UI components, design resources like a sketch UI Kit, icon system, internal and external resources to other things linking out to best practices on popular resource sites like Smashing magazine or CSS-tricks things like that. Page templates, common flows, and UX patterns, brand guidelines. There's so many different ingredients to a design system and again which ingredients your design system contains is going to very much depend on your organization and teams needs. It's no surprise why so many organizations are investing in design systems because they provide a ton of different benefits. They provide benefits to the end user by providing more consistent, cohesive experiences. As users travel from one part of the site to another or from one product to another, they're greeted with a very similar feeling experience and this is important for a lot of different reasons because any time a user has to relearn a new interface pattern, let's say they encounter a date picker across four different sections of a site and each time that date picker is different, they have to relearn. However slightly, relearn the UI conventions for selecting a date. But by having one date picker provided by the design system, the cognition involved in making that decision by choosing that date lessens which allows them to get done what they need to get done faster, which of course is good for them but also good for the business because they're able to maybe check out faster, book a flight, or book a hotel. Whatever the task is at hand is good for the company's bottom line as well as respecting the user's time and attention. While the benefits to the users are big, the real benefits of a design system are mostly internal. They're for the benefit of the teams actually producing the work. The designers, the developers, the QA people, the product people, all of those people benefit greatly from having a design system. The first big benefit of having a design system for a team is that it allows them to launch work faster, and why this is the case, is because we historically had to repeat a lot of unnecessary redundant work. We have a hero unit for our homepage and we have these three tauts or this three cards and every time we have a new page that needs those components, those heroes or those tauts, we had to reinvent them again and again and again and oftentimes with subtle or even sometimes completely different implementation details. So, rather than having to reinvent the card component for the 15th time, the team could instead grab the existing card component from the design system, plug it in, and then focus their efforts on bigger and better tasks. Design systems provide the benefit of launching higher quality work, because again, they're not reinventing things, reinventing the wheel over and over and over again which means that they can instead it iterate over those same UI components in those same patterns baking in better accessibility, flexibility, responsive stuff, localization, animation, all of that stuff means that the quality of the work, the quality of these UI components are elevated with each new iteration. Design systems provide a shared vocabulary that helps bring together different disciplines and different product teams so that they're all on the same page and all speaking the same language. So, rather than the developer is calling a component the utility bar, the designer is calling it the admin bar, and the product team calling it the gray bar across the top, you are able to establish a common vocabulary for what that thing is actually called. Allowing teams to skip over having to have a meeting to discuss the nomenclature to make sure that we're all on the same page. Design systems also make testing easier allowing teams to isolate an individual component and stress test it against responsive design best practices, accessibility best practices, performance best practices, and so on. So, by testing things at the component level and baking in those best practices at the component level, anywhere those components get included will automatically get those benefits for free. Design systems and their accompanying style guides also provide a useful reference for teams, designers, and developers to refer to as they do their day-to-day work. When do you choose an accordion versus tabs? You can refer to your style guide to see when to use one component or another or what to name a component or what conventions you want to use. By having that shared resource to go to, it helps all of the teams workflows go more smoothly. Then lastly, a design system provides a future friendly foundation to build upon for years to come. This is a great thing about design systems, is that it's very foundational. You're not going to solve all of your organization's problems and v1 of your design system. But what having a design system allows is for iteration improvement over time by establishing conventions, establishing components, and building upon them as time goes on, the team and the quality of the work is able to go up and up and up as time goes on. Even if you were to do a massive redesign of your entire organizations, visual identity, color palette, and all that stuff, you still are going to have buttons, you're still going to have cards, you're still going to have topography and iconography and things like that. So, you don't have to throw out the baby with the bathwater. So, the design system can remain as your ongoing design language evolves. There's obviously so many benefits to design system so it's no surprise that so many organizations are investing heavily in their own design systems. Some famous examples include Google's Material Design, Carbon Design system by IBM and heck even the US Government has a design system to power the over 30,000 websites produced by the Federal Government. So, that's just a quick refresher of what a design system is and what benefits they provide. In the next lesson, we're going to talk about how to kick off a successful design system initiative. 3. Kicking Off a Design System Initiative: So how the heck do you even start a design system initiative? There's so many different facets to design system that it can become almost paralyzing to even get started. I found a great first step is to just get a lay of the land of what your digital products are made of. What are your digital products' DNA? There's a few different tools and tactics for rounding up all of the different UI components and styles contained in your digital products. The first is a site called cssstats.com. What CSS STATS does is prints out all of the different style rules contained in your website's style sheet. So, you could go to cssstats.com and just plug in your URL or to whatever your digital products domain is and hit the go button and what it will do is spit out all of your style rules. So, if you look at this page, you can actually plug in various popular sites, we'll stick with Facebook for now and what it will do is it will spit out all of the style rules that is on facebook.com, which as you might imagine are many. So, not only does this give you all of the different style rules and selectors, it also points out all of the 85 unique colors including what looks like 50 shades of grey and different flavors of Facebook blue. What this does is this gives teams the opportunity to round up these different colors and to start to normalize them. Have conversations about what should be in there and what maybe should be modified in order to reduce that number. Same thing goes with background colors, what's the right color of red for error states or green for for success states? Again, what Facebook blue is the right Facebook blue? What are neutral colors in our color palette? What are the different font sizes? What are the different font families and how might we reduce those. Because all of these font families, declarations are a performance hit. So, how do we thoughtfully reduce those numbers and all the way through. So, this is a great tool. We're just getting a snapshot of what your UIs are made of and helps the team facilitate a conversation about which design properties should be staying and what should be going. The next tactic for getting a lay of the land is conducting what I call an interface inventory. What an interface inventory is, is a screenshot exercise that basically the entire team goes on an Easter egg hunt across all of your digital properties, and it rounds up and collects and displays all of the unique UI patterns and puts them all under one roof. I'm going to walk through the different steps of conducting an interface inventory. The first step is rounding up all the troops, rounding up all the different members of the team that are responsible for the success of your design system. This is an important first step because sometimes an individual designer will take it upon themselves to go out and round up all the unique button styles and card components and things like that, but it's not very helpful in isolation because a key benefit of design systems is establishing that shared vocabulary. So, having different perspectives in the room helps galvanize this design system initiative and starts that shared vocabulary between the different team members. So, include designers and developers and QA people and product managers and project managers and all the people that are responsible for the success of your digital products. So, essentially an interface inventory exercise is really just screenshotting a bunch of stuff. Step two is preparing to screenshot. I like to make sure that everyone is using the same tool to capture screenshots. Let's say this might be PowerPoint template or a keynote template or Google Slides or some other mechanism that allows the team to chuck all of their screenshots into one place, so that you can combine them all at the end of the exercise. I've created a Google Slides template that you could use to kick off your own interface inventory exercise. Now, for the main event. Step three is actually screenshotting all of these different distinct UI components. So, the way that this tends to work is we assign a different category of UI component to a different team member. So, the more people you have in the room the better, the more eyeballs you have on your digital properties. There are a bunch of different categories to screenshot. There's global UI components, like different headers and footers. So, some person or a team of people can be responsible for going through and capturing all of the different kinds of headers and footers and states of those components across their digital properties. Another team could be responsible for capturing different image types. Other people can be finding icons, like different magnifying button icons or hamburger icon or arrow icons across your different digital properties. Other people can be focused on typography. Other people can be focused on blocks, like heroes and cards and things like that. Someone else could be on form controls like text areas and text inputs and radio buttons and check boxes and things like that. Another person can be on button duty. You get the idea, but the idea is again to go far and wide across all of your different properties sometimes even including your native properties, in your web properties, in internal facing properties, in external facing properties. The idea is that it really crawl into the dark corners of your user interfaces to capture all the different components that tend to show up. I found this exercise to be helpful as a timed exercise. You could easily spend days or even weeks crawling through the jungles of your UIs. But for the sake of time, it's helpful to just get a snapshot of the DNA of your UIs. I've found that an hour or two is sufficient to get a broad enough footprint of what your UIs are made of. Once you've conducted the screenshot exercise, step four involves presenting your findings. So, each individual team member that was responsible for say finding the buttons will go up to the front of the room and present what they found. This is a really helpful part of the exercise because this is where everyone's able to experience the pain of all of these different buttons components across your different digital properties. It's also here where that shared vocabulary starts to emerge, right? Different team members or different disciplines are going to have different names for the same components. So, it's in this presentation and discussion that the teams able to start to reflect on what the name of these components are, why these components look a certain way or should this thing stay or start to go. All right. So, this provides a really helpful conversation for the entire team to get behind the design system initiative and starts to anticipate the whole design system project that's going to come later. Then the last step of an interface inventory is regrouping and establishing next steps. There's obviously only so much you can do in a couple hours together. So, the working team that's creating the design system could then start to take the findings of that exercise and figure out how to transition that into the design systems roadmap. One of the best things that you could do at the end of the interface inventory exercise is to corral all of the results of that exercise under one roof, in one giant PDF. This is really great because this becomes a tool to help sell the design system initiative to the rest of your teams as well as the people controlling the finances, right? You don't have to be a designer to understand that having 70 unique button styles is a bad idea. So, you could literally drop a PDF or a printout of the interface inventory exercise on your CEOs desk and they will understand why a design system is needed. So in summary, an interface inventory exercise helps point out the inconsistency and gets that lay of the land of what your UIs are actually made of. It points out those inconsistency so that the design system team can start whittling away and sort of figuring out what needs to stay and what needs to go. It's the beginning of that shared vocabulary between team members that will become codified in the design system itself. It also helps establish what the shape of the design system project is even going to be, what UI components are going to need to be contained within the design system, and what's their general priority? Are there lots of forums, are there lots of data tables, are there lots of cards, and things like that. Maybe that can help get a sense of what the priority of the components should be. So once you get a lay of the land of what your UIs are made from, it's super tempting for designers and developers to just dive into the weeds and get designing and get building. But it's important not to act on that instinct and instead take a step back and actually talk to people to figure out what the design system needs to do. Any good design project will start with research and the same is true for a design system initiative. When we tend to think about user research, we tend to think about the people who are using our software. While this is true and they should be involved in a design systems research, the real users of a design system are the designers and the developers, and the actual teams building these user interfaces. By talking to these people, you're able to get a sense of what jobs the design system needs to do in order to be successful at the organization. Again, this is why it's so important not to just dive into building components and designing components because honestly you don't know if those components that you end up designing and building are actually going to meet the real organizational challenges that real team members are experiencing. There's a misconception that research needs to be this huge formal thing but really in fact is about talking to people. So, you can sit down one-on-one with different team members whether they're a designer, developer, QA person, project manager, product owner, and get a sense of what their workflow is like, what parts of their workflow they are not exactly happy with, what things frustrate them, what they would like to see out of the design system? What are the things that they see as being important aspects of the success of the design system initiative? What are potential threats to the design system initiative? In other words, what's going to sink the ship if we don't get it right. All of these conversations help paint the picture of the jobs that the design system needs to do in order to successfully address people's frustrations and lead them to better product design and development. Once you're done with your research, you could immediately transition that into a formal kickoff workshop for the design system initiative. We used to make the mistake of kicking off a session without doing a research first. Those kickoff sessions ended up devolving into the loudest voices in the room, overpowering the rest of everyone, and getting things off track with a bunch of people's pet projects. By doing research first and then doing a kickoff workshop, you're able to use the kick-off session to gather broad consensus for the design system initiative. So kick-off workshop involves getting all the stake holders for the design system initiative in a room together. From here, you can present the findings from your research. What you'll tend to find is that by talking to a bunch of people, different teams are going to emerge, right? Maybe the designer and developer workflow is rough and they're in their own silos. Maybe developers are frustrated by too many different competing technology stacks. Maybe the designers are using to many different tools and it becomes hard to collaborate together. All of these different insights help paint the picture of what the design system needs to do. So, we tend to take those learnings from our research and bucket them into these broad themes. We tend to end up with about 12 to 20 themes for the design system, potential outcomes for the design system initiative. What we do is we hang these themes on the wall and then we have all the stake holders vote on which themes are most important. Out of all the outcomes of the design system initiative these 10 to 20 things, what are the things that it really needs to nail? What are the things that really needs to get right? What we do is we give everyone three post-it notes and have everyone vote on the three goals of the outcome they find to be the most important. What's great about this process is it is very democratic. You don't have to worry about the most extroverted or the highest paid people in the room steamrolling the conversation and distracting everyone. Everyone gets a vote on what they feel is the most important outcome of the design system initiative. By the end of this exercise, you're able to take a step back and actually have a heat map of the priorities of the design system, right? If this thing had to do three things really, really well, what are those three things? Right? What is the pain and the frustration that this design system needs to address? It's not to say that the other goals or outcomes on the design system initiative aren't important or that the team isn't going to address them, it's just that when push comes to shove with limited time resources and money, you have to get some things right. You're not going to be able to cover everything with equal priority. So, by conducting this research and these kick-off exercises, the team is better able to understand what the design system is and what jobs it needs to do. In the next lesson, we're going to talk about how to translate the learnings from that kickoff exercise into choosing pilot projects to set your design system up for success. 4. The Pilot Project: So, you've now conducted an interface inventory that gets you an idea of what your UIs are made from, and you've conducted research and done a kickoff exercise that helps get a broad sense of the priorities of the design system. So, the next step is actually diving in and starting to build the design system. It might be tempting to go in and start building individual components like buttons and cards and headers and things like that. But a truly successful design system is not created in a vacuum. It's connected to the products it serves, and that's the importance of pilot projects. Pilot projects provide an opportunity to build the design system through the lens of real working software. It is only using pilot projects that we're able to truly be able to say that the design system can actually power real working products. So, for instance, a pilot project might be a homepage redesign for your website or it might be redesigning the dashboard screen here or it might be redesigning the frequently asked questions page or something like that right. These slices of products give you an opportunity to establish all the components that are necessary for building those screens. So, how do you choose which pilot projects to kick off your design system initiative with? There's a lot of different criteria involved in choosing a pilot project and one of the main ones is where that project is in its roadmap. If design and development work has already happened and they are started, that ship is probably already sailed. So, you want to be in this sweet spot where you know that the project is happening and the team is planning on building this project like a homepage redesign or something like that, but they haven't actually started the design and development process yet, that becomes an opportunity for the design system team to latch on to that project and help create that project as well as the nascent design system components. There's a lot of other criteria involved in choosing pilot projects and my friend and colleague Dan Moll has written a great post explaining those different criteria. Some of those criteria include the potential for common components. So, we talked about conducting an interface inventory that gives you a better idea of what your products Uls are made from and so you want the pilot project to be able to take some of those boxes. If your interface inventory showed that your organization has loads and loads of forms and data tables, then you probably want to have a pilot project that will give you the opportunity to create form components and data table components. The scope of the pilot project matters a lot too. You don't want to redesign the entire website as a pilot project, that's too big. You want something that you could get your hands around and complete in a couple of weeks or a couple of months. You also want to make sure it's achievable from a technical standpoint. You don't want to have to bite off an entire CMS re-platforming or updating to an entirely new framework as a pilot project that might be a little too cumbersome to overcome in these early days of the design system. You also want to think about the marketing potential for your pilot project. Is this something a project that you could hold up at the end of this process to the rest of the organization? Have everyone else look at it and say "Hooh, I want to do that too"? Coupled with this is the idea of having an available champion, right? The product team you're working with, you want them to be on board with the concept of a design system because they can become a cheerleader and an evangelist for the rest of the organization. In this early day of the design system, you need to have people on board with us and people that are able to roll with the punches, because in the early days of the design system, you're slowly building the airplane as you're flying in. So, you need people that are willing to come along on that journey with you. You don't want to partner with the most skeptical hard to work with people for your initial pilot projects. So, again, choosing pilot projects helps connect the design system to real working software and that's absolutely critical to the success of your design system. So, once you have your pilot projects chosen, now you can get to work and actually build your design system, which brings us to the atomic design methodology. 5. Atomic Design Methodology: The heart and soul of a great design system is a set of reusable, flexible, resilient components. Most people understand the importance of a component driven design in development process. But how exactly do you arrive at this specific components that will be contained in your design system? Enter atomic design. Atomic design is a methodology for thinking about UI's as a thoughtful, hierarchical, interconnected set of components that build real screens. In order to understand atomic design, we're going to take a quick detour back to your high school chemistry class. All matter in the universe is comprised of a finite set of atomic elements; hydrogen, carbon, iron and things like that. These atoms combine together to form molecules and ultimately more complex structures to create all of the complexity in our world and in our universe. That's an incredibly powerful concept. As it happens, we can apply that same concept to our interfaces. In the world of UI design, any user interface can be broken down into a finite set of atomic elements. Things like labels, inputs, and buttons. All these other elements that can't be broken down any further, serve as the foundation, the basic building blocks of our UI's. But atomic design is more than just atoms. There's actually five discrete stages of atomic design. There's atoms, molecules, organisms, templates, and pages. We're going to go through each stage. As we just mentioned, atoms are the basic building blocks of our UI. So, things like labels, inputs, buttons, topography, headings, images, and stuff, they serve as our raw materials. But it's abstract on its own to just see a bunch of buttons or labels floating around in the abstract. So, at the next stage, at the molecule stage, we take those atomic elements and combine them together. So, for instance, a label, an input, and a button might join together to form a single field search form or a newsletter sign-up form. Now all of a sudden, these atoms have a purpose, right. That label is defining that input, clicking that button will submit that form. So, now you have this nice encapsulated component that you could drop in anywhere you need the single field form. An organism is a more complex component that's comprises smaller molecules. So, a header organisms, for instance, might be comprised of a logo atom, a primary navigation molecule, and a search for a molecule. All of those things come together under one roof to form this discreet chunk of UI. Moving up to the template stage, what we do there, is we take our organisms and we combine them together and drop everything into a page layout. So, here you're starting to see a full page take shape. But it's important to stress that at the template level, we're really just defining the content scaffolding or the skeletal system of a page rather than the final product or the final output. At the page stage, we're able to take that content scaffolding or that skeletal system and then pour real representative content and data into it. Now, the page stage is super important because obviously this is what your end users are going to see and interact with. They're going to see your homepage with real imagery and real calls to action and real headlines involved in them. But it's also at the page stage that we're actually able to test the resiliency of the underlying design system. We're able to see if a specific kind of image gets poured into a hero unit, does that hero unit stand up? Right. What if it's a picture of mountains and it's nice and it's peaceful and there's a lot of white space and there's some text overlaying those mountains? That might be nice and easy to read that text. What if we replace that picture of mountains with a noisy group of people? Now it might be a lot harder to read the text that's sitting on top of that image. So, it's playing out real products scenarios that we're able to arrive at sturdy solutions for the underlying components. It's also at the page stage that we're able to play out different scenarios of a template. So, for instance, you might log in to a dashboard of your web application, and for a new user, they might want to see something different. You might want to present a tutorial or an alert message to a new user that veteran users might not see. Your design system needs to be able to handle that real scenario. So, it's at this page stage that we're able to play out real products scenarios that will inform and influence the underlying system. So, atomic design could be applied to literally any user interface. Whether that's a website or a native app or a piece of native software like Sketch or Photoshop or even your bank's ATM kiosk or anything like that. So, let's apply atomic design to an app that a lot of people are familiar with, Instagram. So, Instagram, as we all know, is a photo-sharing app, and if we apply atomic design to this interface, and we explode the Instagram app experience into its atomic elements, we are essentially left with a handful of icon buttons, a handful of texts atoms, and one for the actual photo itself. At the molecule level, you can see those atomic elements come together to form some usable pieces of the interface. But really at the organism level is where things, the meat and potatoes of the Instagram experience come together. Because it's here where the photo organism which includes all of the user metadata, the photo itself as well as the actions and comments for the photo where all that comes together. Of course, this photo organism is the thing that's stacked on top of each other and we scroll through for infinity, right. So, we could see that come together at the template level, which is a pretty simple template just because it's a mobile app. So, it's just these things stacked on top of each other. Then at the page level, is where we're able to take our design system and actually pour real representative content into that template. So, it's at this stage that we're able to test all the different variations, all the real products scenarios that we're going to encounter as a design team. So, for instance, what happens if your user handle is 10 characters long? How does that work? But what happens if somebody tries to enter user handle that's 50 characters long? What happens then? Does it wrap onto two lines, do you have a conversation with the backend team to cap the number, the length of the user accounts? What happens if a photo has zero likes to it? What happens if in photo has a 100 million likes to it? What happens if there's zero comments? What happens if there's 14 layers of nested comments to it? What happens if the photo is a square or a landscape or portrait or a slide show or a boomerang? All of these are real products scenarios that the Instagram design and development team need to cater to. For another example, let's take a look at Facebook. So, earlier, we talked about how you could apply atomic design to literally any user interface. One interface that we're all familiar with, is Facebook. So, what we're going to do, is we're going to take Facebook's interface and literally chop it up into pieces. This is called the component cutoff exercise, documented by web designer Charlotte Jackson. So, what we're looking at here, is atomic designs page stage, right. We're looking at a specific instance of a user interface with real data poured inside of it. So, the first thing we're going to do, is deconstruct this page into its smaller organisms. We're skipping over the template stage just because at the template is essentially this screen only with some of the data abstracted, right. Rather than these specific people in this profile blocks and these specific stories in my feed, it would essentially just be grayed out sort of place holder data. So, since we can't articulate that on paper, we're just going to jump straight into extracting our organisms from this page. So, what I'm going to do, is get to work. All right. So, what we've done, is we've chopped this up into smaller component pieces into these broader organisms. So, it's worth pointing out that organisms can contain other organisms as well. So, let's say the sidebar organisms, for instance, actually still contains some pretty complex pieces of UI like the story's chunk and this event's invite in our pages in our advertisement here. So, what we could do, is actually take this organism and actually break it down even further. So, let's go ahead and do that. All right. So, now, we have even smaller organisms, but they're still organisms. So, now, from here, we can take a specific organism and actually start extracting our molecules from it. So, I'm going to choose the stories organism and actually deconstruct that even further. So, let's go ahead and do that. So, now, we've deconstructed the stories organism and blown it out into a few smaller components. So, you'll see we have a couple buttons hanging off to the top right, we have a title for this block up here. We're going to leave that alone for now. At the bottom, we have this button to see more of your friends. But what I'm going to do is, I'm going to focus on this specific component here. So, we can call this a profile molecule, or we could call it a media block, which is a more generic name for this specific component. But essentially, what we're looking at is an image on the left and a name or a title of some sort and some metadata below it. This is a really important piece of Facebook's UI puzzle. You can see we have our contact list over here using some flavor of this same component. We have it used here, we have it hanging out in our header up here, we have it over here in our sidebar, and it's used a bunch of different places across their site. So, you can see how important it is to be able to address this component because it's deceptively simple. If we take a look at it and you consider there are 2.2 billion users, this component right here has to do a lot of heavy lifting. So, we're talking about names of all shapes and sizes, different languages, different reading directions, things like Arabic or Mandarin or German or other things that tend to not follow the Western style of writing. It's really important for this piece of UI to be able to handle all of those different scenarios. I don't envy their team in the slightest for this because this is a deceptively complex piece of UI. So, now that we have our media block component or a media block molecule or a profile molecule, whatever we want to call this, we can now even deconstruct this even further. So, what I'm going to do is chop this up into its atomic pieces. So, we've deconstructed our media block molecule or our profile molecule down into its atomic elements. So, we have this reusable circular image icon that we're using across the Facebook website. We're using this title atom that is used to display people's names but also calls to action, as well as many, many other things across the site, as well as this general treatment for something we'll call metadata, or it's something that's a little more subtle. It's meant to indicate either a timestamp, or over here, it's a little bit of a description text. But you could see that just even at this atom level, there's a lot of work going on here. So, what happens if a user's profile picture is cropped weirdly and it chops off part of their head, or what happens if they don't have a profile image at all? What's the default thing? What if we want to use some sort of icon or different image for that? All of this, even at the atom level, there's just so much complexity going on here. But the spirit of this is, by controlling all of this at this atom level, by being able to solve very complex, hard problems at the atomic level, whenever these things come together to form these molecules and then come together further to form these organisms, then come together to eventually form these final screens, all of those best practices that happen all the way at the atomic level bubble up and percolate out into all of the UI as a whole. So, Atomic Design can help teams take these big, thorny UI problems, actually break them down into smaller, more digestible pieces, allowing them to design and build things more systematically and then build those components up to form very flexible, resilient products. Thinking about UI design systems through the lens of Atomic Design provides a lot of benefits. The first and biggest one that I've been repeating throughout this lesson is that it's so incredibly important to connect product design and development with system design and development. Atomic Design provides a bridge between those worlds because it's not just the components living in a vacuum off to the side in an abstraction and then your products living elsewhere, it's all of that stuff feeding each other. The design and the development of the system will inform and influence the products that come out the other end, and the products themselves will inform and influence the system. So, for instance, you might have a marketing homepage that has a couple cards, a hero unit, and stuff like that, and then, you might have another product that uses cards in another different way, still using the same card molecule or organism, but it's being applied to different products for different purposes. Applying Atomic Design to your design system workflow allows you to build the whole and the parts of that whole at the same time. You don't design a car by starting with the hubcap or a lug nut and then building up from there, it starts from a whole, cohesive picture of what that car will be, and you will arrive at the parts that comprise that car at the same time. Another advantage Atomic Design provides is, it provides a clear separation between the structure of your UI components and the content that lives inside of them. So, for instance, you might have a reusable card component. In one instance, that card component might house a bunch of product data. In another instance, it might contain a bunch of event data. By creating this clear separation between a component structure and the content that lives inside of it, you're able to create more reusable, agnostic, and flexible UI components. Another thing that Atomic Design provides is a common language for thinking about components as a hierarchy. Terms like component and module and element are a little too abstract, and there's no sense of implied hierarchy here. But terms like atoms, molecules, and organisms contain that sense of hierarchy, where atoms are included in molecules and molecules are included inside of organisms. Now, if you find your team getting tripped up over the terms atoms, molecules, and organisms, it's no big deal. Update your language and your nomenclature to something that makes sense and helps get everyone on board with these concepts. You're able to practice Atomic Design without using the terms atoms, molecules, and organisms. The team at GE that works on the Predix Design System decided to take the Atomic Design methodology and tweak the vocabulary and add a couple of extra steps in there. That helped get them by in for the entire design system initiative. So, now, we've covered what Atomic Design is. It's a mental model for thinking about our UIs as a hierarchical, interconnected set of components that helps build real product screens. But how do we actually apply Atomic Design in the real world? In the next lesson, we're going to talk about how designers and developers can work with Atomic Design in their workflows. 6. Tools of the Trade: So, at it's core Atomic Design is just a mental model. So, how do designers and developers actually apply this mental model to their workflow? How you apply atomic design to your workflow is going to depend on what role you play in a design system initiative. Designers tend to work in tools like Sketch or Envision Studio or Figma or Adobe XD or other static design environments. Thankfully, these tools have evolved over the last few years to include things like symbols and components that are able to be nested inside of one another. So, we're able to accomplish Atomic Design in these static design tools. So, in a tool-like sketch, we're able to define our atoms, define our molecules, and also define our organisms are more complex components, and what we're able to do with this is now make a connection between those atoms, molecules, and organisms. So, for instance, if we wanted to change let's say the border radius of our buttons, I could come in here update our border-radius value and hit "Save," and what I'm able to do is see how making that change impacted our teaser component that's using our button atom, and you can see that those borders are now rounded, and then if we go into our organisms which are making a teaser list which is a collection of teaser elements, we're able to see those buttons updated as well. So, all that's to say, you're able to create this interconnected system of components of these symbols and make changes in one place and have those changes ripple out to anywhere that that component is included. So while designers are using tools like Sketch and Figma and Adobe XD and Envision Studio, developers tend to build out components in a different kind of environment. I tend to call this the front-end workshop environment, and what a front-end workshop environment is is a place where you're able to define components and put the real dynamic data into those components without necessarily having to wire it up to the actual functioning application. There's a bunch of different tools out there that provide these front-end workshop environments. We've rounded up a collection of these front-end workshop tools on a site called Styleguides.IO, which is a collection of resources all about design systems. There's a whole bunch of front-end workshop environments out there that are quite popular including storybook, pattern lab, fractal, view DS and more. What we're going to do is show a demo of using pattern lab to create a design systems components and pilot projects screens. So, what we did was we created a fictitious e-commerce website in pattern lab. So you can see the homepage here has some up-close shots of shoes with some promo images and a footer and all of that good stuff, and then we're able to click into our product categories to see women shoes and men shoes and kids shoes and then we're able to click in to a product detail page that shows the specific product a user wants to buy, all the way through the shopping card experience, and checkout workflow. So, this is a great example of a website that has a lot going on with it. We have more splashy marketing stuff. We have more utilitarian product detail pages and of course some forums for users to check out. So, all of this is created with 100 lying design system, and what pattern lab allows us to do, is to visualize the design systems underlying components. So, jumping into the index page, you are able to see all of the even subatomic pieces like our brand color palette and are neutral color palette and utility colors as well as our topography and font sizes and headings and other things like that, and as we scroll through here you'll see things like icons in different image types and different blocks like our hero unit and promo block that we'll get into in a little bit. But you can see all of the underlying atoms, molecules, and organisms laid bare so that the team is able to have conversations about them. So, the cool thing is is that we're able to use pattern lab to traverse between these different patterns. These atoms, molecules, organisms, templates and pages. So, for instance, we're able to zoom in on an individual atom which helps us have a conversation about this specific UI component. So, this is a helpful place where designers and developers are able to come together to talk about what dimensions these product images are going to be. So, you can see this is a 600 by 400 image. But again as we talked about these atoms aren't terribly useful on their own. So, what we're able to do is use pattern labs lineage feature to show where this pattern actually get used. So, it says that the Stack Block Image is used in our Stacked Block molecule. So, we can click in here, and actually now view this stacked block component which is a product card or something where we could put product information, but also maybe some other information down the road. So, from here, we're able to say we have the stacked block card, where does this get use? And it says this is included in our stack block list which is a list of these components which all come together to form this grid that might be used for something like a product grade or something like that. Now from here, we're able to say the stack block lists is included in these following patterns up to the category template. So, now, we're able to see this product grade start to come to life. We're able to see this stacked block lists start to be applied to something very specific. Now, from here if we look at where this template is being used, is saying we're using it for our kids category or men's category and so on and so forth. So, if I click into a specific page, we're able to visualize what that template looks like with men's shoe data poured into it. So, again this is a real products scenario. This company needs to sell men's shoes and this UI is accomplishing that. But then we're also able to to navigate to different areas that are using the exact same template, but pouring different content inside of these UI templates. So, whether you're a designer using nested symbols are components in a tool-like sketch or sigma or you're a developer using a tool like pattern lab or storybook to nest components inside of one another in code, you're building up this set of interconnected, interdependent components to build out real screens, and those screens are going to be dictated by your pilot projects. If the gig is building out a new homepage, then great that's going to provide you the opportunity to create a hero component and some card components in your header, in your footer and things like that. If you're the gig is redesigning the checkout flow that's going to give you some form fields and some other things. So, the idea is that we're using those pilot projects to design and build all the components that will ultimately power those products. By using a front end workshop environment and using the static design tools and they're nested components, you're able to accomplish atomic design systems right there are all under one roof. So, this process can be used to build your initial design system, but one of the crucial things about a design system is making sure that it stands the test of time. How do you set your design system not for long-term success and handle not just the present-day scenarios of your products, but also address future outcomes of your products. In the next lesson, we're going to cover how to do that. 7. Using Your System for Future Work: So, building out a design system through the lens of a handful of pilot projects is a great way to establish a set of reusable, flexible components that could help build real products. But pilot projects are just that. They're pilots. They're not going to address every single scenario that your organization is going to run into. Sometimes, you're going to find yourself looking for a component, plugging it in, and finding that it gets you maybe 90 percent of the way there. But in order to accomplish something you need this extra 10 percent in order for it to actually work properly. So, what we're going to do is talk about ongoing product work and how to roll that in with the ongoing evolution of your design system. So, let's come back to our hypothetical shoe company. Let's just say that the boss has always been a little reluctant to offer things that were on sale. So, everything that we see on our demo is a full price item, right? So our men's category, our women's category, our kids category has nothing but full price items. But the times have change. And let's say that, that strategy wasn't working out, so, reluctantly, the boss comes around, and he says, "Okay. We have to include a sales section on our website now." So, how does that work? Because this actually involves updating our UI to address this new business scenario. So, what we need to do is we need to update our navigation to include a sales section. And we could update our homepage and include a new section below our main promo items, with this "On Sale" sort of tout section. Then we could also click into our sale category page, which is the exact same category page as the women, men's, and kids categories, but we have a couple UI differences that become clear. So, we have a change to our stacked block pattern where we're including and adding this little sale flag in the top right corner of our component and we also have this update to our price. Which you can see the original price knocked out, and the new sale price appearing in its place. So, the cool thing is, is that we're still able to reuse the main bits of this component but we're going to create a variation of that component that allows us to address this sales scenario. So, you'll see that in our pattern library, we now have a stacked block. And then we make a variation of that pattern, writing a bit of HTML and a bit of CSS, and making those changes to address this scenario. Now, this stacked block could handle not just normal products but also sale products. The result is a sturdier component, a more flexible component that's able to travel to more places across the website. So - that's great - with just a couple of tweaks to a component, we're able to address a brand new product scenario. This is what Yesenia Perez-Cruz calls Scenario-Driven Design Systems. The business has a problem, has a goal, that they're trying to accomplish, and the design system needs to help accomplish those goals. So, it's through the lens of the ongoing product work that the system becomes stronger and more flexible over time. Let's use another example of a holiday gift guide. The boss comes in and says, "It's almost holiday time. This is an important time of the year for us. We make a lot of our revenue. But, let's be honest, our current category pages aren't as splashy as we would like them to be." So, what we want to do is we want to address that. So, if you look at our existing product category pages, it's possible to create a holiday gift guide as the title and then feature the different products that are going to be on sale for the holidays. But we could do something better. Because we have these reusable components - some of which are on our homepage - that are bigger and splashier, maybe we could reuse some of those components to create a more splashy, elegant holiday gift guide section. So, what we're going to do is we're going to take this hero component, and we're going to plug it in above our product grid. And we're going to arrive at a brand new design, using existing components in our design system. So, this is really, really powerful because this allows us to mix and match existing components to achieve an entirely new experience, all in a matter of minutes. Historically, creating something like a holiday gift guide would take weeks or maybe even months to accomplish. But once you have a set of reusable, flexible, resilient components that you could rearrange in all sorts of different ways, you could literally plug this stuff in a matter of minutes. That's is a huge gain for the entire team. Now, of course, that's not to say that, "It's just so easy that all we need to do is drag and drop a couple of components in there and go to lunch early." There's still, obviously, a lot of hard product design work that needs to happen. But here's the thing. Now, that the designers and developers don't have to rebuild the hero components from the ground up each time, they're able to focus on bigger, better problems. Maybe it's about translating that hero component in two different languages, maybe it's sourcing different artwork or maybe it's about spending more time playing with animation or other things, right? This is all an opportunity to free designers and developers up for more worthwhile work. By connecting your ongoing product design work with the evolution of your design system, each iteration over the components of your design system results in a sturdier, more flexible, resilient, more powerful system. That's an incredibly powerful concept. 8. Final Thoughts: So that's that. You've made it to the end of the course. Hopefully by now you understand how design systems help power real products and how you could use the atomic design methodology in your design and development workflows in order to create your initial design system, but also to help guide your ongoing designed system efforts. I'd loved to hear how you're using atomic design in your own workflow, and I'd also love to hear if you're getting hung up or frustrated or stuck in any part of your design system initiative. So feel free to jump into the discussion section below and keep the conversation going. Thank you so much for joining me in this class, and I really hope that this helps you in your own sign system journey. 9. Explore More Classes on Skillshare: [MUSIC]