A well-implemented design system can simplify the user experience of your software by ensuring the individual UI elements come from a single source of truth. In theory, that should help you maintain a level of UX integrity not found anywhere else. Using a design system allows your team to be more efficient during every step of the pipeline. Imagine discussing a new interface with your designers, developers, and stakeholders — a design system allows you to plan the layout, choose the components, and build the interface without having to spend hours on the design process. In theory, you’ve already finished the UX testing, QA, and stakeholder approval for the individual components of your pattern library. This allows you to transition into a rapid development environment that’s as simple as building the template. In reality, it can take years to make a robust design system, but you should consider heading that direction sooner than later. In this article, I’m going to discuss the basics of an atomic pattern library and how you can integrate that with your entire process, from design to development.
For years, designers relied on style guides so their developers could build UI elements that looked the same in every template. Developers waste a lot of time referencing the style guide to ensure their UI elements match the design. What if we could eliminate that process entirely? Enter: Atomic Design. Originally conceived by Brad Frost, Atomic Design separates your software into tiered UI elements: atoms, molecules, organisms, templates, and pages. At a rudimentary level, it’s like building software with Legos — there are thousands of pieces with specific dimensions that, when assembled correctly, make an object. Further still, using those modular components allows you to assemble the object the same way every time. As a designer, developer, or stakeholder, you don’t need to manufacture the Legos, you just put them together.
Using an atomic pattern library as the source of truth for your development process not only allows for rapid development, it also ensures a better user experience for new projects. Assuming you’ve user tested the UI elements in your library, you can include them in your new project without worrying about the usability of the interactions they create. If you find yourself needing a new UI element, your user experience designers can research the best implementation of that element and put it in the library for use in your new project and every future project after that. If that’s not enough to convince you atomic design is the future, let’s talk about a real-world implementation of this philosophy.
When I was hired at Bio-Techne, they didn’t have a streamlined development process, let alone a pattern library or even a website style guide. The best they could offer me was a branding style guide from corporate headquarters (basically just colors and fonts). They recently adopted the agile development approach but relied on their stakeholders for design feedback. I consider that a cardinal sin of design. I love NN/g’s mantra: you are not the user. A stakeholder cannot possibly define the design for a project without introducing bias. Stakeholders should be available for general, product-specific guidance, but the user experience team should define the design based on their knowledge of standard UI elements, interactions, and actual user testing results. That data, rooted in empathy, will always result in a better user experience.
Before moving forward at Bio-Techne, I had to define our overall design and development strategy. Since I wanted consistency and efficiency, we decided to work towards an atomic pattern library. The ultimate goal was to create a single source of truth for all design and development assets. It’s even possible to integrate your code-based pattern library with certain prototyping tools to keep the designers on the same page as the developers. It’s certainly complicated to get everything configured and communicating properly, but once you do, it’s an amazing way to do more work in less time. It also ensures a better user experience for every interface you build.