Episode 3 - Starting strong: applying atomic design and choosing a pilot

Brad Frost: So you might have a blog powered by WordPress, an application built in React, another one built in Vue, another one built in Angular, you have native software in the mix, so iOS and Android. Your users don't care about any of that stuff, right? They don't care where this content was generated from or which framework was used to build which thing.

The design system itself needs to be sort of bigger than any one implementation of a technology. Frameworks come and go, it's like summer fashion, fall fashion, spring fashion. Next year there will be some new GitHub repository with more stars and whatever and everyone will be chasing that. And if you sort of put all of your eggs in that one basket, all of a sudden that design system isn't going to be able to travel to the new hotness that's right around the corner.

MAIN TITLE: DESIGN SYSTEMS—MASTERING DESIGN AT SCALE

Dan Mall: I think the value of pilots for a design system is kind of like the value for a pilot for a TV show, right? It's like before you know that the audience is going to resonate with this particular show, you do a pilot. And the point of the pilot is just to test out a concept. You don't do the whole show, you just film one episode and you see how people react to the characters and you see how people react to the storyline and the general premise of the show, and if that goes well, the network is usually like, "All right, we'll produce more episodes of the show."

SECTION TITLE: PILOT PROJECTS

Dan Mall: I think pilots for a design system should have that same kind of goal and have that same idea to them where you don't need to build a whole thing to see if this is worth having in your suite of products. You just need to build a small thing to go, "All right, can we use this actually in our design system?" Having a pilot that is small in nature is a really important thing to be able to feed your design system.

Josh Clark: I love your comparison to a pilot of a TV show because a lot of times also, you have this much-loved show and you go back and you watch the original episode and you don't even recognize it. You're like, "Oh my gosh, this is such a shallow thing." I think that that's an important thing to know too, is you don't have to get it complete or perfect right off the bat. In fact, you just want sort of something to start and know that it's going to grow from there, and then using that as a foundation to build your next project. And so it's sort of both design system and product evolve together. I'm contributing my work to this design system of which applications and websites are individual instances of it. I think that that sort of changes the way that you think of it.

There's this really productive, virtuous cycle between product and design system where really it's a single system is the way to think of it, where you are building product and you're extracting useful things for reuse out of into the design system.

Dan Mall:

I think there's a good cadence that you get into, too. If you do the first couple right, you get some momentum that you're building of pilots. And I think there's the way to choose a right pilot, there's a sweet spot. I also think there's criteria for making a good pilot project, too. I've got seven criteria for that in particular. And you can even create a scorecard of these criteria.

It's one thing for the CEO to say, "Well, I think this has great market potential, so we should do this as a pilot," but it scores really low on all the other categories. So the first thing is mixing all the categories together. It's got to do all of these things really well, and then you can evaluate on the same objective scale from project to project. And if you do that for a number of them, you could say, "Well, listen, we're just going to take the top three highest scorers, and those are the first three that we're going to use as pilots for our design system."

The first thing on your scorecard is how much of this can be commonly used? That's common components, common flow. So for example, a header is probably something you're going to use on maybe every website that you make. So a header or a footer or cards, that's usually where people start on design systems and pilot projects.

The second thing, now, gets a little bit more nuanced. The second thing is, well, how can we have highly-valued components or patterns? Maybe that's only use on one or two products, but you get a lot of mileage out of it. An example of that is a date picker or a calendar widget or something like that. You may only use that on a handful of products, but that goes a long way that if you already have that in the can, you can reuse that on other products. So that's the second criteria.

The third criteria is technical feasibility. How possible is it on the technical side to actually accomplish this project? Is it going to require a large refactor to be able to do this? Are you dependent on some technology, you've got to build this augmented reality something to be able to do this pilot? Things like that make this less likely of a good pilot.

The fourth thing I think is a really important one, which is the available champion. Design systems are more than just components and patterns and principles, they're really about the people. The people who can champion the stuff. So a good pilot project will usually have a good champion that will, at the end of the pilot, hold this up to the rest of the company and say, "See how we made a really great thing," and actually be kind of an evangelist for it. Projects that have really good champions or a good product manager behind them, those are usually good ones for pilot projects.

The next one is scope. A good pilot will take maybe a couple of weeks to do. If you're trying to bite of a project that's going to be months long or years long, you're not really going to see the results fast enough to fold into your design system. So just knowing that something is possible within a short time frame makes for a good pilot project.

The next category is technical independence, and this kind of related to technical feasibility, too, but technical independence is about how separate can this project be? You certainly want to be wired into your tech stack, but you don't want to be mired down by the tech stack in order to do this. So if you're, for example, redoing your whole CMS platform, that might not be a good pilot project to be able to do this because there's just so much dependence in other parts of the system.

The last criteria is, and maybe this is the most important one, is marketing potential. A good pilot project will be something that other people can look at across the organization and go, "Wow, we want to do something like that, too." So that might be the most visible project at your company, that might be something where the CEO's pet project, it might be something that the favored team in the company's actually working on, but something that actually plays well in maybe marketing videos or something like that makes for a good pilot project.

SECTION TITLE: STYLE GUIDES

Brad Frost: It can be overwhelming how many different facets there are to a design system initiative. You have to establish design principles, you need to talk about code conventions, you have to talk about tools and design tokens and components and oh, there's so many moving parts. So we've actually found sometimes it's helpful to just stand up a style guide website from day one of the project, even if it looks like an empty shell with no styling or anything like that, no content. But it's there, and that becomes an opportunity for the team right from day one to start collecting these assets and collecting these things that are floating around the organization and starting to sort of corral them all under the roof of the style guide website.

And this helps provide a bit of a roadmap for the design team. As you go through your design system initiative, you're able to poke around your in-progress style guide website and see which aspects of the style guide website are not populated yet. The style guide website can serve as the single source of truth for the design system. It is the thing that you could hold up to the rest of your organization, and even the world, as a way of saying, "Here's how we do things at this organization." It crucially provides a watering hole for all disciplines to come to and get value from. Designers should be able to come to the style guide website and get crucial information about how to design better products. Developers should be able to go to the style guide website and get an understanding of how to utilize certain components and what code conventions they should follow.

Product owners can come to the style guide website to have an understanding of what materials they have to work with and what conventions and guidelines they should be following in their own products. A style guide website really does bring everyone together under one roof. It helps break down barriers between discipline silos, product silos, and platform silos.

SECTION TITLE: WORKSHOP/STOREFRONT

One useful analogy we've found for talking about design system tools is this concept of the workshop and the storefront. My wife is a jewelry designer and a metalsmith, and she has a workshop environment that allows her to be creative and productive. It gives her an environment where she's able to try things, prototype things, burn things, saw things out, get messy, get dirty, experiment, and ultimately come out that process with a new, finished piece. But she also has a storefront environment that allows her to showcase her finished work and also surround it with contextual information that helps potential customers purchase her goods.

What does this have to do with design systems? Well, we sort of have a workshop environment and a storefront environment as well. Our workshop environment should be designed for the teams building the design system to be creative and productive, to prototype things, to stress-test things, to fail at things, and iterate over things in order to arrive at sturdy, resilient, robust, assessable, performant UI components.

We also need a home for those finished components to live, and that takes the form of a style guide website. The style guide websites are the storefront environments for our design systems. It is the happy home for all of the ingredients that are contained within your design system. You'll see this on sites like lightningdesignsystem.com or carbondesignsystem.com or material.io. So it's in this storefront environment that we're able to showcase and explain the design principles that govern the system. The high-level UX in design guidelines all the way through low-level components like cards and buttons and accordions and things like that. And it's in this environment that we're able to sort of write documentation and show these components in action and show the code and show different resources for those components. This, quite literally, is the instruction manual for how to use these components in products.

SECTION TITLE: TECH AGNOSTIC

How do we actually create a technology agnostic design system that also is simultaneously integrated with the tools and technologies that are in play at your organization? It's hard work as it turns out. In our work together, we like to see the sort of canonical technology agnostic design system. In the world of the web, has sort of HTML, CSS, and JavaScript, and a lightweight sort of presentational JavaScript. After all, that's the stuff that gets rendered in the browser. That's the stuff that gets sent down the pipes to actual users.

But then from there, what actually sort of renders that markup and those styles and that JavaScript could differ wildly between different products, so some subset of an organization's products might be built on Angular, and another subset might be built on React, and another might be built on Drupal, which uses the Twig templating engine to sort of render its markup. So the idea is that you sort of take this canonical agnostic design system, and then sort of a create a technology-specific flavor of that design system. And then sort of from there, individual applications can take that technology-specific flavor of the design system and plug that into their code base.

Then, what ends up happening is that if a change gets made to the system, the change gets made at the top level. So let's say the accordion is broken and none of the accordion panels can open. Well, fix that bug at the highest, most sort of agnostic level, and then sort of make sure that every technology-specific flavor of that gets that fix as well, and then individual applications can sort of pull down the latest and greatest changes.

With managing this whole ecosystem requires a great deal of discipline, it means establishing proper workflows and processes around sort of deploying the design system and making changes to the design system and accepting contributions and just sort of managing all the moving parts. And it sounds scary, but really once you establish those conventions and once you codify those processes, it becomes manageable to sort of not just create one great looking design system in the abstract, but also to sort of feed that design system into very real and specific technology implementations, which can then power real products.

SECTION TITLE: ATOMIC DESIGN

We created atomic design, which is a methodology for creating thoughtful, deliberate, hierarchical design systems. What atomic design is, is it's a way to step through how our smallest atomic units of a UI is able to sort of build a final product. Atomic design consists of five discrete stages that all happen concurrently. Atoms, molecules, organisms, templates, and pages.

Our bodies, this floor, this stool, the planets, the stars, are all sort of built from the same stuff. And actually, so it goes in our UI's. At the end of the day, if you were to blow up any UI, you're going to end up with things like buttons and form fields and images and typography headings and things like that.

We're able to sort of apply the same process that happens in the natural world to our user interfaces, hence atomic design. So we have atoms. What are the atomic elements of our UI's? Well, we have things like labels, inputs, buttons, images, headings, things like that. These are things that can't be broken down any further without ceasing to be useful. These are the basic building blocks of our UI's. The problem with atoms, though, is that they're not technically useful on their own. It's whenever we move up a level to molecules where we start to see these things come to life.

When we get to the molecule stage, we take a group of atoms, say a label, an input, and a button, and actually put those things together to form sort of a single-field form, like a site search or a newsletter signup form. Now, suddenly, these atoms have meaning. They have utility. This label atom now describes this input atom. Now clicking this button will submit that form. So now we have this nice little encapsulated component that we could drop in anywhere we need this sort of single field form. But again, that's also not terribly useful just as its own sort of little units. And now we can, at the organism level, take these molecules, say like a search form molecule, and plug that into a bigger, more complex component.

So a header organism, for instance, you might find on any website. You might see a logo atom, a primary navigation molecule, a search form molecule, all sort of locked up in this discrete chunk of interface. This complex component is what I call an organism. So an organism might be comprised of a bunch of different things like a logo, like a navigation, like a form, or it could be a grid of cards. So it's the same card molecule repeated over and over and over again to form this sort of discrete chunk of UI.

The big difference between molecules and organisms is that molecules are simple components and organisms are more complex components. That's really the distinction, but it really sort of lends itself to thinking about UI's as this sort of infinitely nested set of components, almost sort of like Russian nesting dolls. These little things are included in bigger things which are included in even bigger things.

So then from there we move up to templates, and what templates do is sort of take these organisms and other molecules and combine them together into a final screen. So here's where we're able to sort of start seeing the UI come together to form a cohesive whole. But it's important to point out that at the template level what we're really doing is establishing the sort of template skeletal system. So we're not focused on the specific content that's going to be poured in to this UI, but rather just sort of scaffolding out the basic shape of the UI. And it's here where we're able to sort of see these patterns start to interplay with one another in the context of a page layout.

And then lastly, the fifth and most concrete step of atomic design is the page level. So it's at the page level where we take our template and we pour in real representative content from a real product into that template to bring it to life. Now, this step is hugely important because this is what your end users are going to see and interact with, but it's also here where we're able to sort of see all of the components, the smaller components, come together to form a cohesive whole. It's here where we're able to test the resiliency of these components.

By building the design system using the atomic design methodology, it allows teams to sort of thoughtfully set aside components as you need them, and by sort of building these things and building the actual pilot projects and real product screens under the same roof as the actual components, you're more prone to sort of build for a reuse and you're able to sort of reach for these existing components rather than being tempted to sort of, yet again, build a new version of a card or a new version of a block of some other sort.