How Atomic Design Simplified Our Large-Scale Migration Project

When dealing with large design and development teams, we use an approach called atomic design. It’s a system that breaks down elements into small parts and enforces a level of organization perfectly suited to projects with multiple collaborating stakeholders.

The system breaks design pieces down into Atoms, Molecules, Organisms, Templates, and Pages. This approach asks designers and developers to create a component library which would allow them to get off the ground quickly since they don't need to rewrite or rework design elements from scratch.

We recently used this approach for our large migration project with Workhuman. Here’s how we did it:

First, a bit of knowledge, Atomic Design Elements are a mix-and-match approach allowing developers to reuse, repurpose, or pair atomic components with other elements to form new, more complex ones.

We used Storybook as a tool to have a dedicated environment for these design elements to live. It gives us a visual representation of all the elements and lets us test how they will look on mobile and desktop. And, thanks to Storybook’s accessibility extension, we were able to address and fix any accessibility violations in the early design to create a new site that is fully accessible from the beginning. Later in the project, we leveraged Wave, Lighthouse, and manual testing/checklists to make sure the site remained accessible.

How does a design go from idea to launch?

First, a visual design team provides a finalized design. In this case, we started on Figma with a finalized design, and a developer was able to notice which pieces exist in the design system and which need to be added to the atomic system.

We offered some feedback which generally revolved around a few things:

• Reminding or encouraging designers to use elements (atoms and molecules) they previously created when designing page components instead of introducing new variations of them

• Attempting to consolidate components in order to achieve more true component reuse. Sometimes designers may introduce an increasing quantity of component variations, which can add clutter and overhead to the system both for developers and content authors and we try to avoid that wherever possible.

• Simplifying component and page interaction, such as navigation elements and form designs. Sometimes a design can be too ambitious, and it needs to be dialed back

Next, frontend development begins in Storybook on the components using mock data. As seen in Workhuman’s new FAQ section, an accordion component will begin simply as an atom, AKA a single question and answer, and then more than one of those blocks will be put together for a molecule. Finally, as an organism, we’ll bring three of those blocks together with a title and subtitle.

When taking that organism to Contentful, it must be represented in a content model. It matches the design with a headline and FAQ section. Content modeling is carefully considered and completed within the CMS.

Next, pages are constructed in the CMS and the component is placed on a page as needed. On the Contentful side, the page will include all of the content mentioned and allow the content author to edit as needed.

Finally, the component is quality-checked and ensured that it’s integrated into pages as expected.

This year Workhuman launched its new site on a headless CMS that will make deploying content on any digital platform easier than ever. We’re honored to have collaborated with them on this impressive project and proud of everyone’s hard work.

Explore More:

• Thinking of a CMS Migration? Consider the Following First

• What You Need to Know About Contentful