A first-hand look at applying Atomic Design to a scrum project

I’m currently engaged in an app dev project where we’re using Scrum methodology to design and build. It’s going quite well. As we began the project, development brought up Atomic Design and wanted to add it to our process. I’ve read a lot of Brad Frost’s work on the subject and definitely see the wide ranging benefits of this approach. But from how I understood Atomic Design, it was a style-guide approach that’s employed once a style is defined to maintain consistency across digital platforms and screens.

Can Atomic Design be used as part of your design thinking from the start?

First, the good:

Atomic Design has kept the designers honest. As we’ve built out our components and styles, there’s been occasions where we’ve shifted a label for an input field from left-aligned to center aligned. The particular element was a bit different from other fields and it just felt “right.” But did it really have to be different? No, and we changed it back.

Because we are working in scrum, UX is rushing to stay ahead of dev as they think out the screens that are to come. They’re sketching furiously on whiteboards and then moving on to the next feature. As more of the Atomic Design style guide is fleshed out, our visual designer is able to translate a whiteboard sketch easily into fully designed comps (more on “comps below). There’s less cognitive load on the designer in terms of how to design the sketch. Tellingly, earlier in the project when less of the style guide was defined, the designer struggled a bit working from just a whiteboard sketch. More thought from his end and more detailed work from UX was needed. Now that our style guide is more complete, this extra effort is no longer needed.

Second, the hard:

There’s still some friction between the development side and the design side. We print out comps of the various pages and pin them to gator boards so we can review and react to them. Developers have occasionally remarked, “With Atomic Design we really should never be building out full page comps.” This misses the point.

The blunt fact is that the comps aren’t for developers. As designers, we’re thinking through the requirements and challenges and figuring out the best way to design a solution. This necessarily requires a holistic approach.
 
 We take the comps and and drop them into UXPin and build lightweight prototypes that are used to conduct iterative testing with users. This has greatly informed our designs, resulting in us simplifying, enhancing, and pivoting. This could not be done with small components alone.

We also encountered confusion between development and design about what was intended by the various atoms/molecules/organisms. Both sides are to blame here, and it came out — constructively — in a Sprint retrospective. The result was additional conversation to set expectations and tweak process. This has helped immensely.

Atomic Design is a great framework for development AND design in the building of software. But it does need to be flexible to allow creative exploration and to allow the team (because it’s not just designers) to think about the whole product in context. Amazing design is greater than the sum of its individual parts.