In the early days of the web (we're talking early nineties here, so I was about 15 at the time), there was the concept of "pages" for everything. The idea of the internet having pages, like books, was an understood concept. Clicking a link on a "webpage" would show a new "page". Tim Berners Lee invented the World Wide Web as a way to share documents, so it makes sense that this what our understanding of digital web properties were in the beginning. Most webpages were used for putting printed materials online. Browsers and monitors were one or two sizes and mobile devices didn't exist yet.
Here are some sweet examples of webpages built in the 90s.
Fast forward to now and we are still using the language of pages to talk about digital properties. "How is the homepage coming long? How long will you need to build out a 10 page website? How will we ever redesign a website with 20,000 pages?!?" And now instead of having to support one or two screen sizes and browsers, digital technologists have to think about dozens of devices, including TV screens, game consoles and watches, smartphones and desktops, screen sizes, hardware and software. Digital properties need to be more connected than ever. And it's only going to get more complex.
Digital Organizations are also growing, with multiple web properties to maintain, content scattered across different content management systems (Wordpress, Drupal, etc), and duplicated codebases and visual identities for each one. How can everyone within an organization speak in one voice? How do vendors know which hex colours to use or how to correctly use the brand’s logo? How does a content editor know what options they have available to display featured content?
Building digital products like lego
To keep our sanity, we need to break apart the idea of the page, and think about legos. Legos consist of small pieces, but putting a bunch of them together offers infinite flexibility with what you can create. The same pieces can be used to build a semi truck, corvette or race car, it all depends on how you assemble those pieces together.
Image from Atomic Design
Digital technologists are pushing for more "lego-like" modular pieces to build websites. Atomic design is one of these principles. Building off of chemistry and using a similar language, the idea behind it is that you have Atoms, Molecules, and Organisms (the lego building blocks), and these items are put together to build Templates and Pages (the final deliverables that the client sees).
Image from Atomic Design
Basically, Atomic design consists of:
- Atoms: UI elements that can’t be broken down any further and serve as the elemental building blocks of an interface.
- Molecules: collections of atoms that form relatively simple UI components.
- Organisms: relatively complex components that form discrete sections of an interface.
- Templates: place components within a layout and demonstrate the design’s underlying content structure.
- Pages: apply real content to templates and articulate variations to demonstrate the final UI and test the resilience of the design system.
For a more in-depth description - see below.
Atoms
Just like how Atoms are the foundational building blocks of matter, they are also the foundational pieces of our user interfaces. Atoms can include basic HTML elements like headings, labels, inputs and buttons. Atoms should include all of your base styles that can't be broken down any further without ceasing to be functional.
In the context of a pattern library, atoms demonstrate all your base styles at a glance, which can be a helpful reference to keep coming back to as you develop and maintain your design system. But like atoms in the natural world, interface atoms don’t exist in a vacuum and only really come to life once combined with other items to become molecules or organisms.
Molecules
In interfaces, molecules are relatively simple groups of UI elements functioning together as a unit. For example, a heading, a paragraph element and a button can join together to create a callout molecule.
Creating simple components helps UI designers and developers adhere to the single responsibility principle, an age-old computer science precept that encourages a “do one thing and do it well” mentality. Burdening a single pattern with too much complexity makes software unwieldy. Therefore, creating simple UI molecules makes testing easier, encourages reusability, and promotes consistency throughout the interface.
Organisms
Organisms are the next step can be thought of as a grouping of molecules together. While a user interface normally has a bunch of atoms and a bunch of molecules, organisms are a smaller group and are mapped to distinct sections of an interface. A header or a footer organism are some common use cases for organisms.
Templates
Templates is where we depart from the chemistry analogy we've been using up until now. Now that we have our lego building blocks and a language around how we are grouping them together we can put these pieces together into something the client or user sees and interacts with.
Templates are how you show the structure of all your pieces working together on the page, built into a layout and also articulating the design's underlying content structure. A good example of a template would be Home Page Template, with includes a Header Organism, a Callout Molecule, and a Footer Organism.
It's worth pointing out that Templates are about the content structure of the page, and not the final page content. The template is about setting the guidelines for the final page content when you see how all your components look and function together. For example, once you see a template come together you can recommend a word count limit for Headings, or some size guidelines for images that are used for Call out molecules.
Pages
Pages are the final iteration with real representative content in place. The page stage is the most concrete stage of atomic design, and it’s important for some rather obvious reasons. This is what users will see and interact with when they visit your experience. This is the deliverable that your stakeholders will sign off on. And this is where you see all those components coming together to form a beautiful and functional user interface, which is exciting part.
Seeing real content and imagery in the context of the user interface elements helps stress-test all the atoms, molecules and organisms you have created. Does everything look great and function together as it should? If the answer is no, then we can loop back and modify our molecules, organisms, and templates to better address our content’s needs.
Pages are also where you can provide a place to show variations in your templates and solutions to differences in content and imagery and use-cases, such as:
- A user has one item in their shopping cart and another user has ten items in their cart.
- A web app’s dashboard typically shows recent activity, but that section is empty or hidden for first-time users.
- One article headline might be 40 characters long, while another article headline might be 340 characters long.
- Users with administrative privileges might see additional buttons and options on their dashboard compared to users who aren’t admins.
Put these ingredients together and this system is super powerful. Is the page not fully working when everything is together? Modify the pieces that make up the page and see what works best with your content needs. The parts of our designs influence the whole, and the whole influences the parts. The two are intertwined, and atomic design embraces this fact.
Atomic design gives us a structure to deep-dive into the details of a user interface, but to also step back and see everything working together as a whole. One important thing to keep in mind is that atomic design is not a linear process. We don't start with our atoms in isolation and cross our fingers that everything will come together properly. Don't think of the process as "Step 1: atoms, Step 2: molecules" Approach it as a mental model that allows us to concurrently create final user interfaces and their underlying design systems. To adjust the details in the atoms and then see how that affects the whole.
Thinking about user interfaces as lego blocks that can be put together in a multitude of ways, that have been stress-tested in isolation and also when combined with other elements, helps everyone on a project team understand what we are building and why. It makes digital properties more robust, flexible when content needs change, and more maintainable by both clients and agencies.
The Digital Product Glossary of Terms
One of the most difficult parts of working with an agency on a digital product, is the unbelievable amount of industry jargon we use in daily dialogue. So we created a 'Digital Product Glossary-O-Terms' to help you familiarize yourself with the lingo.
