Designing a Content-First Approach
I first heard of “Atomic Design” in a presentation by Jeremy Keith at Breaking Development Nashville in 2011. He gave the opening keynote entitled, “There is No Mobile Web,” in which he challenged us to tackle “content first” web design instead of creating layouts into which we pour our content. Jeremy went on to describe how he creates “pattern portfolios” beginning with the “atoms” of a site before he ever thinks about the layout of specific pages. This idea was very appealing to me because it addressed a fundamental challenge we were facing—how can we design for the flexible complexity that is the web? In fact, the concept is something I brought back to Sparkbox with the hope of integrating it into our workflow. I’ll be honest, we struggled.
Only months before this conference, I had read a brilliant piece by Mark Boulton about designing from the content out. I started writing about how we were attempting to do this, and we’ve been evolving how we work ever since.
Burning the Candle at Both Ends
At Sparkbox, we try to burn the candle at both ends by making progress on the whole as well as on the parts. Often, this means we’re using a tool like Photoshop or Sketch to both design the “atoms” in our system, but also to rough together those atoms and get a sense for how they feel in the context where they’ll be experienced by our users. We’ve found that style prototypes can be a great tool for getting atoms together on a page. Samantha does this with Style Tiles. Dan does it with Element Collages. Steve has written about something similar to a style prototype… Honestly, all these are valid approaches.
Communicating Hierarchy Across Viewport Widths
One idea that I’ve been trying to express in our workshops is how important it is to establish and maintain hierarchy across viewport widths. As we lose screen real estate, we also lose some of the tools we have to communicate that hierarchy. This is especially critical as you begin to incorporate concepts like atomic design into your workflow, because changing a single component without considering how it interacts with other components in your design system may inadvertently change the perceived priority of an experience. While I do see great value in what Brad and Dave are doing with Pattern Lab, we’ve found that this kind of atomic thinking must be used in tandem with a more holistic view. We have to consider how all these atoms, molecules, and organisms work together to communicate priority—even across viewport widths. At Sparkbox, we use content priority guides and wireframes in addition to content prototypes.
If there’s one thing I’ve learned in my experience working on larger projects, it’s that modularity is a requirement of maintainable systems. The challenge is balance, but the reward is well worth the effort. I can whole-heartedly recommend adopting atomic thinking—I only want to do so with a caution to keep pulse on the priority being established as you design and build your modules. As Carl Sagan said, “The beauty of a living thing is not the atoms that go into it, but the way those atoms are put together.”