This is part of our How We Work series of blog posts. Today, we’re talking about how we use Atomic UX design.
We incorporate Atomic design methodologies into our process. Atomic design helps us to validate our prototypes with user testing at the earliest design stages. This can save a lot of time, but more importantly, it creates a better product. As we validate prototypes, our development team moves through iterative cycles. The result is a beautiful working software that's been tested backward and forward.
Atomic design is based on Atomic Theory. If you slept through high school chemistry, don't worry — here's all you need to know:
- Atoms: The basic building blocks of any system, such as inputs, buttons, images, and links. At this level, we define how these parts are presented in active and inactive states, their animations, workflows, and interactions with other parts.
- Molecules: Natural groupings of atoms are defined as molecules. A common molecule is an address form.
- Organisms: A collection of molecules creates a whole component, defined as an organism. While molecules are smaller parts — such as a login form or a navigation menu — organisms are whole sections.
- Templates: A first look at "screens." It's good practice to envision a desktop/phone/tablet template for the same "screens" or component sets.
- Pages: Real content, placed in a template for testing. Includes images and copy, with the goal of providing a solid feel for how the component work together.
- Project DNA: Commonly known as a Living Style Guide, the Project DNA contains every element of the Atomic UX Design Process including colors, fonts, CSS and HTML. Changing elements within the Project DNA are reflected over the whole project.
Design and development, together forever
Far too often, software design and development happen in their respective little worlds - which leads to a whole lot of missed opportunity. At Very, we believe this is unfortunate and unnecessary. So we adopted Atomic UX, a methodology that helps us close the gap between design and development. Here's how it works:
- Designers work on "atoms," "molecules," and "organisms" that align with small job stories. They stay only an iteration or two ahead of engineers — and no further.
- Templates and pages are largely born out of the workflow mapping process, but their exact structure remains in flux, improving with each minor job story and iteration.
- At the end of our atomic UX process, the Project DNA documents every atomic interface element for ease of use and future design and development.
Mapping out the workflow is a critical step in atomic UX. It serves a more important purpose than the sitemap, which often falls short. Through the workflow, we can facilitate discussions very early in the process around API requirements, user flows, core pathways, business workflows, and components that give designers, front-end developers and back-end developers a shared orientation to the project.
During this process, we carefully define user views, user actions and possible workflows with the corresponding organisms and molecules. This begins with writting job stories.
They can't all be happy paths
Below is a simple example of a workflow for a Login process illustrating a forgotten password use case.
With any kind of form entry, users inevitably will encounter an error. Because a site map is limited to what's on screen, the presentation of that error and its resolution pathway are often overlooked
A workflow map, on the other hand, includes real world objects as well as everything that happens off screen, or off the core site map. So it covers not only the "Happy" paths but the "Sad" paths, too — which are a reality for any platform where information will be entered.
Stepping into the greys
From the workflow mapping, we step "Into the Greys," where we begin assembling atomic elements into templates, as illustrated below.
It's more than mapping out components. We document how they behave and how they translate and react to different environments — like mobile responsiveness.