Last active Aug 29, 2015

Atomic Design discusses the importance of crafting robust design systems, and introduces a methodology for which to create smart, deliberate, interface systems.

The book will begin by addressing the "why": why designers should care about thinking about Web interfaces in a more systematic way. I'll discuss the history of modular designsystems (after all, this type of thinking been around for a long while now), but discuss how the ever-shifting Web landscape is making systematic thinking a necessity.

The first section will also discuss the emerging trends and techniques that encourage more systematic thinking: style tiles, element collages, pattern libraries, UI frameworks, and more. And while I'll certainly extol the virtues of these techniques, I'll also bring to light a lot of the shortcomings and frustrations of UI frameworks and pattern libraries. This sets the stage to introduce a more sound, deliberate way of constructing an interface system.

The second chapter will define atomic design. Atomic design is an interface designmethodology consisting of five distinct stages:

1. Atoms
2. Molecules
3. Organisms
4. Templates
5. Pages

The chapter will go on to explain the first three (non-page level) stages of atomic design:atoms, molecules, and organisms. I'll define what each stage is, and discuss the advantages and challenges of each.

Chapter three will dive into the two remaining stages of atomic design: templates and pages. At this level we break the chemistry analogy and transition into language that makes more sense to clients and final output. Templates are webpage-level documents which provide context for these relatively abstract molecules and organisms, and focus oncontent structure (such as character length, image size, etc) rather than actual representative content.

Pages are the final stage of atomic design. Pages are specific instances of templates and swap out placeholder content with real representative content to give an accurate depiction of what a user will ultimately see. This stage is essential for testing the effectiveness of thedesign system, and provides a place to test variations in templates (for example demonstrating an article containing a 40-character-long headline and another article with a 340-character-long headline).

Chapter three will discuss the importance of separating content structure with real representative content. Too often designs are handed off to be integrated only to find out they look like garbage when best-case-scenario FPO content is replaced with the actualcontent. Or worse, the design is entirely unfeasible. I'll discuss the delicate dance between FPO content and real content, stress testing a design system, and providing much-needed context for atoms, molecules, and organisms.

This chapter will recap the atomic design process, and discuss the merits of constructing both the final product and the underlying system concurrently. Both The Part and The Whole have a place in the design process, and the ability to traverse between abstract and concrete is one of atomic design's biggest advantages. Sometimes you need to see the forest, and sometimes you need to see the trees.

Chapter one explains why. Chapter two and three are about the what. Chapter four is all about how. Chapter four will discuss applying atomic design to the reader's Web designprocess.

This chapter will discuss tools and techniques to create atomic design systems. I'll introduce Pattern Lab, a tool Dave Olsen and I created in order to execute atomic designsystems. I'll explain the gist of using Pattern Lab and its various features, but I want to be cognizant of not focusing too much on this specific tool. While I know it's an effective tool for me and others, I understand that it might not be a perfect fit for all readers. The book is more about promoting the idea of atomic design rather than any specific tool.

I'll introduce techniques for design teams to get started with systematic design. One particularly useful technique is conducting an interface inventory. I'll define what an interface inventory is and how to conduct one. I'll also reference other tools (like Stlyify.me and Nicole Sullivan's Typo-O-Matic) that help deconstruct an existing interface into its component parts. I'll also discuss pattern library tools and resources to help designers kickstart their own design systems.

Everyone's design process is different, so I'll also discuss how to introduce and integrateatomic design into cross-disciplinary Web design teams. I'll also provide practical advice for getting buy-in from colleagues and clients.

The book will conclude by recapping why thinking in a more systematic way is becoming increasingly-necessary. I'll talk about the merits of atomic design, and remind people how they can get started. I will leave on a note of "What's next?" for design systems. Right now, for me the most obvious challenge is to make systematic design the default mode of thinking for designers, agencies, and organizations. I think there's a tremendous opportunity for design systems to help people craft more consistency,