Atomic Design in Action: Real-world Implementation and Takeaways

Atomic Design in Action: Real-world Implementation and Takeaways

3 Mar 2021

3 Mar 2021

Krzysztof Podobiński

Krzysztof Podobiński

Atomic Design in Action: Real-world Implementation and Takeaways - cover graphic
Atomic Design in Action: Real-world Implementation and Takeaways - cover graphic
Atomic Design in Action: Real-world Implementation and Takeaways - cover graphic

Diving into the intricate world of design systems, our team took a leap by implementing Atomic Design in a live production environment.

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:


Pros:

  1. Navigation: With atomic, you grasp the component complexity by its level. A form with simple inputs? That's a molecule!

  2. Business through design: You can gauge the size and function of a component without peeking at its code. Handy, right?

  3. Component breakdown: Atomic urges you to split or group components, promoting reusability and component integrity.

  4. High reusability: Since you're dissecting components, you find more use-cases for them. Plus, you're less likely to reinvent the wheel.

  5. Testing: Smaller components make testing a breeze. Keep them isolated and consider visual testing with snapshots.

Cons:

  1. Limited scaling: While we can expand, we can't shrink beyond atoms.

  2. Overwhelming for newbies: It takes a minute for newcomers to grasp Atomic. Patience is the key.

  3. 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.


Description List


Inline Horizontal List


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.


Helper visualisation: The white flashing results from reloading. Observe the shifts in border colours for clarity.


What We'd Do Differently

In hindsight, we could've moulded 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.


Final Thoughts

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, mould it, and create a design system that caters to your unique needs. Happy designing!

Diving into the intricate world of design systems, our team took a leap by implementing Atomic Design in a live production environment.

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:


Pros:

  1. Navigation: With atomic, you grasp the component complexity by its level. A form with simple inputs? That's a molecule!

  2. Business through design: You can gauge the size and function of a component without peeking at its code. Handy, right?

  3. Component breakdown: Atomic urges you to split or group components, promoting reusability and component integrity.

  4. High reusability: Since you're dissecting components, you find more use-cases for them. Plus, you're less likely to reinvent the wheel.

  5. Testing: Smaller components make testing a breeze. Keep them isolated and consider visual testing with snapshots.

Cons:

  1. Limited scaling: While we can expand, we can't shrink beyond atoms.

  2. Overwhelming for newbies: It takes a minute for newcomers to grasp Atomic. Patience is the key.

  3. 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.


Description List


Inline Horizontal List


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.


Helper visualisation: The white flashing results from reloading. Observe the shifts in border colours for clarity.


What We'd Do Differently

In hindsight, we could've moulded 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.


Final Thoughts

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, mould it, and create a design system that caters to your unique needs. Happy designing!

Diving into the intricate world of design systems, our team took a leap by implementing Atomic Design in a live production environment.

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:


Pros:

  1. Navigation: With atomic, you grasp the component complexity by its level. A form with simple inputs? That's a molecule!

  2. Business through design: You can gauge the size and function of a component without peeking at its code. Handy, right?

  3. Component breakdown: Atomic urges you to split or group components, promoting reusability and component integrity.

  4. High reusability: Since you're dissecting components, you find more use-cases for them. Plus, you're less likely to reinvent the wheel.

  5. Testing: Smaller components make testing a breeze. Keep them isolated and consider visual testing with snapshots.

Cons:

  1. Limited scaling: While we can expand, we can't shrink beyond atoms.

  2. Overwhelming for newbies: It takes a minute for newcomers to grasp Atomic. Patience is the key.

  3. 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.


Description List


Inline Horizontal List


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.


Helper visualisation: The white flashing results from reloading. Observe the shifts in border colours for clarity.


What We'd Do Differently

In hindsight, we could've moulded 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.


Final Thoughts

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, mould it, and create a design system that caters to your unique needs. Happy designing!

Start a project

Are you a changemaker? Elevate your vision with a partnership dedicated to amplifying your impact!

💌 Join our newsletter

Receive insightful, innovator-focused content from global product experts — directly in your mail box, always free

Address & company info


Chmielna 73B / 14,
00-801 Warsaw, PL

VAT-EU (NIP): PL7831824606
REGON: 387099056
KRS: 0000861621

💌 Join our newsletter

Receive insightful, innovator-focused content from global product experts — directly in your mail box, always free

Address & company info


Chmielna 73B / 14,
00-801 Warsaw, PL

VAT-EU (NIP): PL7831824606
REGON: 387099056
KRS: 0000861621

💌 Join our newsletter

Receive insightful, innovator-focused content from global product experts — directly in your mail box, always free

Address & company info


Chmielna 73B / 14,
00-801 Warsaw, PL

VAT-EU (NIP): PL7831824606
REGON: 387099056
KRS: 0000861621