As a front-end developer, it’s common to experience problems when working with a designer and the files they share.
Let's talk about what those are, why they happen, and why atomic design can help.
Common design hand-off problems
- Too many one-off designs that take time away from clearing backlog issues
- Too much time is spent maintaining one-off designs
- Devs brought into the conversation after design and stakeholders have approved a design
- Stakeholders don’t understand the time and trade-offs involved with creating one-off components from scratch
These complaints are common because communication is hard—especially between different teams.
How can we take positive steps to solve this communication problem and create cohesion between teams?
Let’s talk about the ways you can prevent them from happening.
Adopt a design system based on the atomic design methodology
Why atomic design?
If you haven’t heard of atomic design — it is a methodology for designing and building user interfaces in a systematic and structured way.
The methodology was created by Brad Frost and is based on the idea that complex user interfaces can be broken down into smaller, more manageable parts or building blocks.
Atomic design uses 5 levels
Atoms
Atoms are the smallest building blocks representing UI elements like buttons, inputs, and labels.
Molecules
Molecules are groups of atoms that work together to form more complex UI elements like forms, search bars, and product cards.
Organisms
Organisms are groups of molecules and atoms that make up entire UI components, such as headers, footers, and navigation bars.
Templates
Templates are a higher level of abstraction that defines the layout and structure of a page or interface.
Pages
Pages represent specific instances of templates with real content and data.
The atomic system creates consistency
The key idea behind atomic design is that these building blocks can be combined and reused in various combinations to create consistent and scalable user interfaces. Using atomic design, teams can create a more efficient and cohesive process by building reusable components used across multiple projects.
This leads to
- Faster development times
- Easier maintenance
- A more consistent user experience
Creating alignment with design hand-offs
There are many benefits to adopting an atomic design system, such as ensuring consistency, flexibility, reusability, scalability, and maintainability of your project.
However, let's focus on how this system can improve your team's efficiency.
Adopting an atomic design system creates a shared understanding and common operating picture between development and design. With both teams aware of available components and capabilities, you can reduce surprise designs and better forecast work for one-off builds.
Evaluate your current process
Before implementing a system, evaluate your tooling.
Questions to ask your team
- How are designs generated and shared with the dev team?
- Is there a central location for all designs, or individual files per design?
- How does the design team know what coded components are actually capable of?
- How is the dev team communicating available components back to the design team?
Your tooling can go a long way in creating a shared understanding of your design system. Modern tools can help teams stay disciplined and stick to the system.
Free template to gather this data
We put together a design system interview template that has all the questions you need to help organize and gather this data from everyone on your product team.
Setting best practices with two sources of truth
While it may seem counterintuitive, you need two sources of truth to define your design system.
Design team sets expectations
The design team maintains one source of truth representing the expectations for a component—what it should look like and be capable of.
Development team manages execution
The dev team maintains the second source of truth, representing the execution of a component—what it looks like and is capable of. Most teams deliver designs to devs but fall short of communicating execution back to design.
Design system tools to accomplish this
Figma — manage expectations
The design team maintains a Figma file as the expectation for your project.
Figma can enforce theming (color names/values, typography, spacing) and use component instances across your design system so changes propagate. It’s also a great place for devs and designers to discuss behavior.
Storybook — manage execution
The development team maintains a Storybook instance as the execution of the project.
Storybook is an open-source tool for building UI components and pages in isolation. It can display multiple variants, attributes, and documentation for components.
Share these tools with each other
Occasionally, execution diverges from expectations. When this happens, address disparities quickly. A governance model will help. At a minimum, hold a brief huddle after completing a component to align expectations with execution.
Free template to create your own governance model
Our Design System Governance Template is great for this.
By fostering a shared understanding of current capabilities among Dev and Design, you can increase productivity, reduce frustration, and expedite the creation of new features.
You've got this
Implementing a new atomic design system may seem daunting, but it can yield significant benefits. With constructive team dialogue, a measured approach, and disciplined tooling, the process will become second nature.
Design system resources
We have resources to assist you in jump-starting this process:
- Design Systems in Figma Course
- Shipwright - Free Figma UI Kit and Design System
- Getting Started with Design Systems - Free Video Series
- Design Tokens in Figma
- Design System Governance Template