1% betterDesignMethodology

Intro to Atomic Design

By June 10, 2020June 29th, 2020No Comments

Ahh, good old design systems. The bane of my existence.

On most projects I’ve worked on, design systems were a nice-to-have more than an MVP. We’ll get to it later, it’s outdated, we don’t have time… until it dies on the vine. It’s an unfortunate scenario, but one that I’ve experienced frequently.

I’ve spent some time reading about Brad Frost’s Atomic Design methodology to gain a 1% better understanding. Future writings will focus on applying AD to create design systems in Sketch or Figma.

Design systems vs pattern libraries 

Pattern libraries – a standardized base of components and interaction patterns to create a unified design language. Google, IBM, Salesforce all have public pattern libraries. [links]

Design system – reusable building blocks with a set of standards guiding the use of those blocks. They are assembled together to build digital solutions.

Think of Ikea furniture – you have the actual parts of the Ikea furniture that you unpack from a box. But without a manual, you can’t put it together. That instructions manual helps you put together your new piece of furniture. It also saves your sanity.

Design systems feed the pattern libraries. The effort comes down to (visual) designers, which hand off their work to FED, who then maintain and organize the codebase. Ultimately, this handy work is only seen by designers and developers. Other departments rely on department-specific documents: copywriters and tone and voice guidelines, marketing and ad requirement docs, back-end developers and development guidelines, etc.

Atomic design is not a linear process, but rather a mental model to help us think of our user interfaces as both a cohesive whole and a collection of parts at the same time.

Brad Frost

Atomic design: atoms

The parallel between pattern libraries and the would outside our screens is chemistry. Which is exactly what Brad Frost relies on when coming up with Atomic Design.

The natural world has building blocks of all matter. An atom is the smallest constituent unit of matter. On their own, they’re fairly abstract and not useful. However, they are good as a reference in the content of a pattern library.

When referring to web interfaces, atoms are the HTML tags such as input fields, buttons. Even more abstract elements such as color palettes, fonts, and animation can be considered atoms. To dive further, we might consider every pixel an atom, but that takes the cake.

Atoms are a good reference in the context of a pattern library. You can see your global styles laid out at a glance. Like that poster you’ve seen in your 5th grade.

Atomic design: molecule

Things are getting more tangible when combining atoms. Molecules are groups of atoms bound together. They take their own properties and serve as the backbone of design systems. While molecules can be complex rules of thumb, they are a relatively simple combination of atoms built for reuse.

Form label, input, buttons, icons aren’t useful individually, yet together create a form.

Atomic design: organisms

Organisms are groups of molecules joined together to form a distinct section of an interface.

While clients aren’t interested in molecules or atoms of a design system, organisms enable them to see final interfaces to take shape.

Atomic design: templates

The fun bit! At this stage, the chemistry analogy goes by the wayside. The language that makes more sense to clients and stakeholders takes over. Templates consist of groups of organisms stitched together. It’s here where the design comes together and a layout emerges.

Benefits of design systems

End-user – the experience feels more cohesive and consistent. Everything has a similar feel and look.

  • If a user encounters two different date pickers on the same website, they have to relearn (however slightly) the conventions to use each date picker. Having a standard date picker outlined in the design system (and pattern library) lessons their cognition involvement. In turn, they would be able to complete their task (selecting a date) faster. Cohesive and consistent experience for the end-user is beneficial to the company’s bottom line. (I can go on for days about this). It also respects their time and attention.

Teams – designers, developers, QA, product teams all rely on approaching deadlines.

  • Getting rid of redundant work (are the buttons rounded? what color is the hover-over state?) allows everyone to focus on important tasks. This puts higher quality work above tedious design discussions by the team. Instead both design and dev teams can spend their effort on accommodating accessibility, flexibility, animation, and any other improvements.
  • It also enables teams to have a cohesive language when describing elements within the design system. Everyone is on the same page.
  • There is one reference point for which component to use, when to use an accordion vs a tab, how components are named, etc. This shared resource helps workflow makes work go smoothly.

Most important of all, it’s future-proofing. The design system is not going to be all-encompassing in version 1.0. However, having documentation of everything allows establishing conventions. It allows for a quick scan of what is missing or what needs to be revisited.

Phew, that’s a lot to digest.

The problem of these libraries is that they are frequently created after a project launches. If even then. By that point, it’s difficult to run around unifying assets and code.

A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.

Nathan Curtis