Atomic Design in Action: Real-world Implementation and Takeaways
Diving into the intricate world of design systems, our team took a leap by implementing Atomic Design in a live production environment.
Mar 3, 2021
What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
Static and dynamic content editing
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
How to customize formatting for each rich text
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
Before we plunge into the depths of our Atomic Design adventure, a quick primer: if the term "Atomic Design" leaves you a tad befuddled, I recommend hitting pause and checking out Brad Frost's Atomic Design explanation. Not only will it clear things up, but it's also a pretty enlightening read.
Our Why for Going Atomic
To set the stage, here's a rundown of the challenges staring us in the face:
Needing to share components across multiple apps.
Ensuring every component ticked off specific design boxes.
Aiming for lightning-fast component creation.
Wanting an isolated sanctuary (or repository) for our component library.
Prepping ourselves for the birth of 100+ components.
Desiring an isolated playground for component creation (hello, storybook!).
Keeping our project structure user-friendly and intuitive.
Now, here's the kicker: our implementation predominantly revolved around React, styled-components, and TypeScript. However, and this is crucial, Atomic Design isn’t exclusive to these technologies. In fact, you can roll out Atomic in virtually any tech environment.
The conventional project structure targets apps as a whole, not merely component libraries. Our business lens prompted us to classify components into the basics (think buttons, inputs) and those with a touch more complexity, based on features. With a burgeoning list of 100+ components, deciding on names and ensuring smooth navigation was no walk in the park.
Enter Atomic Design
With its unique approach of breaking down designs into the tiniest bits, it seemed tailor-made for our scenario. But was it really?
Pros and Cons of Going Atomic
Let’s dissect our Atomic journey:
Navigation: With atomic, you grasp the component complexity by its level. A form with simple inputs? That's a molecule!
Business Through Design: You can gauge the size and function of a component without peeking at its code. Handy, right?
Component Breakdown: Atomic urges you to split or group components, promoting reusability and component integrity.
High Reusability: Since you're dissecting components, you find more use-cases for them. Plus, you're less likely to reinvent the wheel.
Testing: Smaller components make testing a breeze. Keep them isolated and consider visual testing with snapshots.
Limited Scaling: While we can expand, we can't shrink beyond atoms.
Overwhelming for Newbies: It takes a minute for newcomers to grasp Atomic. Patience is the key.
Added Work: Sometimes, splitting feels like unnecessary work. But in the long run, it aids navigation and speeds up development.
Challenges and Solutions
Keeping Atoms Small: We stumbled upon atoms with overflowing props, mostly styling-related. Our fix? We introduced style variants to manage this.
Organisms and Pages Complexity: Shifting style props to variants and using pre-configured variants helped. Additionally, using React’s local state management or externalizing code aided in maintaining clarity.
Layout Implementation: We faced challenges in developing layouts without real components inside. To navigate this, we developed a helper to showcase the layout in isolation.
What We'd Do Differently
In hindsight, we could've molded Atomic to fit our unique needs better. Also, introducing variants earlier would've smoothed out a lot of bumps. Making changes in shared components can be tricky, so a proactive approach is beneficial.
Atomic Design is fantastic, but it's not a one-size-fits-all. It shines in specific scenarios, like a component library or projects that need sharable components. Initially, it can feel like you're navigating a maze, but once you're in, the development speed is akin to a sports car on an open highway.
For me, Atomic’s true value emerged in the latter stages of development. Creating context-free components paves the way for reusability, saving heaps of time in the long run.
If you're on the fence about Atomic, consider using it as a baseline. Adapt it, mold it, and create a design system that caters to your unique needs. Happy designing!