{"id":18496,"date":"2019-11-11T17:28:58","date_gmt":"2019-11-11T17:28:58","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=18496"},"modified":"2020-11-30T09:50:59","modified_gmt":"2020-11-30T09:50:59","slug":"atomic-design-system-of-components","status":"publish","type":"post","link":"https:\/\/www.shopjessicabuckley.com\/blog\/atomic-design-system-of-components\/","title":{"rendered":"Atomic Design: How to Design Systems of Components"},"content":{"rendered":"

Nowadays, digital products must be able to exist across any and all devices, screen sizes, and mediums at the same time:
\n\"Digital<\/a>Every type of medium can now display our interfaces elements<\/p>\n

<\/div>
<\/svg><\/div>

\"So why the hell are we still designing our products by \u201cpage\u201d or by screen?!\"<\/em><\/p><\/span><\/blockquote>\n

Instead, we should be creating beautiful and easy access to content, regardless of device, screen size or context.<\/p>\n

By keeping this in mind and by being inspired by Modular Design, Brad Frost formulated the method of Atomic Design, in which everything begins with the smallest element of the interface: the atom. This metaphor allows us to understand what we are creating and especially how we are going to create it.<\/p>\n

I was convinced by this approach which finally allowed us to think about the part and the whole at the same time, have a global vision of a product or a brand, and also get closer to the way developers are working.<\/p>\n

So I thought to myself:
\n\u201cOf course, that\u2019s it! We need to work like this!\u201d
\n<\/em>But honestly, I didn\u2019t have a clue about how to do this\u2026<\/p>\n

It took me several months and some concrete projects before gaining an idea of what \u201cdesigning in atomic\u201d really meant and what that was going to change in my everyday life as a designer.<\/p>\n

In this article, I\u2019ll go over a bit of what I\u2019ve learned and what to keep in mind when designing systems of components with Atomic Design.<\/p>\n

For what kind of project?<\/h2>\n

For me, every project, big or small can be designed with atomic in mind.<\/p>\n

It gathers teams around a shared vision. The components are easy to reuse, edit and combine together so that the evolutions of the product will be simpler. And as for smaller projects\u2026 Well, every small project could one day become a big project, no?<\/p>\n

I also think that, contrary to popular belief, the Atomic Design methodology is not just for web projects \u2026 Quite the opposite in fact! I was able to introduce Atomic Design into a personal project (an iOS app for cleaning your address book named TouchUp<\/a>) and the developer with whom I worked really appreciated this approach. It saved us a lot of time when we wanted to quickly develop and iterate the product.<\/p>\n

And for those who wonder if it\u2019s possible to build a system of components while still remaining creative, I recommend reading this article: \u201cAtomic Design & creativity<\/a>\u201d<\/p>\n

How is this different than before?<\/h2>\n

People often ask me:
\n\u201cBut how is this different than the way we worked before?\u201d<\/em><\/p>\n

I see Atomic Design as a slightly different approach to interface design but one which can make a great impact in the end.<\/p>\n

<\/div>
<\/svg><\/div>

\"The part shapes the whole and the whole shapes the part\"<\/em><\/p><\/span><\/blockquote>\n

Until recently, we designed all the screens of a product, and then we cut it into small components to make specifications or UI Kits:
\n\"design<\/a>Before: we deconstructed screens to make components<\/p>\n

One of the problems was that the components created in this way were not generic and they weren\u2019t dependent on each other. The reuse of components was thus very limited: our design system<\/a> was restrictive.<\/p>\n

Today, the idea of Atomic Design is, to begin with, common raw material (atoms) with which we can build the rest of the project:
\n\"\"<\/a>Today: we start from atoms and we build the rest from there<\/p>\n

We have thus not only an \u201cair de famille\u201d between all the screens but also a system which offers infinite design possibilities!<\/p>\n

Everything starts with brand identity<\/h2>\n

Now you might be wondering:
\n\u201cWhere do we begin if we want to design in an atomic way?\u201d<\/em><\/p>\n

To which I answer, rather logically: with atoms ;)<\/p>\n

Thus the first thing which we are going to do is to create a unique visual language for our product that will be our starting point. This is what is going to define our atoms, our raw material and it is obviously very close from the brand identity.<\/p>\n

This visual language must be strong, easy to build upon, and free itself from the medium on which it is going to be displayed; it has to be able to work everywhere!<\/p>\n

The Gretel agency<\/a>, for example, made some remarkable work on the Netflix identity:
\n\"Netflix<\/a>Netflix visual language: strong, recognizable and easy to build upon
\nAnd thanks to a strong identity, we feel that we have all the material to release our first atoms: colors, typographic choices, forms, shadows, spaces, rhythms, animations principles\u2026<\/p>\n

It is thus essential to spend time designing this identity, thinking about what makes the difference, the uniqueness of a brand or a product.<\/p>\n

Let\u2019s continue with the components<\/h2>\n

Now that we have this raw material (still very abstract for the moment), we can now create our first components according to the objectives of the product and the initial user flow which we\u2019ll have already identified.<\/p>\n

Begin with key features<\/h3>\n

What really frightens designers who begin creating a system of components is to have to make components which are connected to nothing \u2026 Obviously, we aren\u2019t going to create a shopping basket component if there is no purchase element in our product! That wouldn\u2019t make any sense!<\/p>\n

The first components are going to be closely linked to the product or the brand objectives.<\/p>\n

And once more, to get rid of this notion of \u201cpage\u201d, I insist on the fact that we are going to focus on features or user flow, not screens\u2026<\/p>\n

We are going to focus on the action which we want our user to do and on the components that are needed to accomplish this action. The number of screens will then vary, according to the context: maybe we\u2019ll need half of the screen on desktop to display this component versus 3 consecutive screens on smartphone\u2026<\/p>\n

Enrich the system<\/strong><\/h3>\n

Next, in order to enrich the system, we are going to make round trips between the already existing components and new features:
\n\"enrich<\/a>Enrich the system by making round trips between the already existing components and new features<\/p>\n

The first components will help to create the first screens, and the first screens will help to create new components in the system or to change the existing ones.<\/p>\n

Think generic<\/h3>\n

\"\"<\/a><\/p>\n

When we design with atomic, we always have to keep in mind that the same component is going to be reused in very different contexts.<\/p>\n

<\/div>
<\/svg><\/div>

\"We are thus going to make a real distinction between the structure of an element and its contents.\"<\/em><\/p><\/span><\/blockquote>\n

For example, if I create a specific component that is a \u201ccontacts list,\u201d I\u2019m very quickly going to transform it into a generic component that will simply be a \u201clist\u201d item.<\/p>\n

And I am then going to think about some possible variations of this component: What if I add or remove an element? And if the text runs onto 2 lines? What will be the responsive behavior of this component?
\n\"responsiveTransforming a specific component into a generic one<\/p>\n

Having anticipated these variations is going to allow me then to use this component to create other ones:<\/p>\n

\"\"<\/a>Possible variations of a generic component<\/p>\n

This work is necessary if we want our system to be both reusable and rich at the same time.<\/p>\n

Think fluid<\/h3>\n

We still tend to think of responsive design as a reorganization of blocks on specific breakpoints.<\/p>\n

Yet it\u2019s the components themselves which have to have their own breakpoints and their own fluid behavior.<\/p>\n

And thanks to software like Sketch, we can finally test the various responsive behavior of our components and define what we want to be fluid or what has to remain fixed:
\n\"\"<\/a>We have to anticipate the fluid behaviour of our components<\/p>\n

We can also imagine that a component can be totally different in a context or in another.<\/p>\n

For example, a button with a round corner on desktop may become a simple circle with an icon on a smartwatch.<\/p>\n

The part and the whole<\/h3>\n

One of the really interesting things building a system of components with Atomic Design is that we are conscious of creating a set of elements that depend on each other.
\n
\n\"\"<\/a>Working out the details before taking a step back to verify the results in the greater scheme of things<\/p>\n

We then constantly zoom-in and zoom-out of our work. We are going to spend time on a detail, a micro-interaction, or the refining of a component, before we take a step back to verify what it looks like in context, before taking yet another step back to see what that makes as a whole.<\/p>\n

This is the way we\u2019ll refine the brand identity, develop components and verify that the system works.<\/p>\n


\n\"\"<\/a><\/p>\n

All of our components are linked to our atoms. And as everything is connected, we are going to be able to easily make modifications on a part of the system and verify the repercussion on the rest of the system!<\/p>\n

<\/div>
<\/svg><\/div>

\"We\u2019re so lucky today as designers: we finally have tools which are adapted to create lively and evolving systems.\"<\/em><\/p><\/span><\/blockquote>\n

Of course, there are programs like Sketch which allow us to create shared styles and to mutualize the similar components but I\u2019m sure that we are going to see a lot more in the next few years.<\/p>\n

We can at last, just like developers, have our own style guides and build entire systems around these style guides. A modification to an atom of our system will automatically reverberate across all the components which use this atom:
\n\"\"<\/a>All components are linked to the atoms<\/p>\n

We realize very quickly how the modification of a component can affect the whole system.<\/p>\n

By interlinking all of our components to each other, we also realize that if we create a new component, it\u2019s the heart of the system that is going to be impacted, not just an isolated screen.<\/p>\n

Share the system<\/h2>\n

Sharing of the system is essential to keeping consistency between various products.<\/p>\n

We all know that we can very quickly lose this consistency when we work alone on a project, but it\u2019s even more difficult when we work with other designers, which is happening more and more often.<\/p>\n

Here again, we now have tools which allow us to really work in a team around a common system.<\/p>\n

There are shared libraries<\/a> for Sketch or those of Adobe for example, which allow us to have a single source of truth, accessible by all and always up to date:<\/p>\n

\"\"<\/a>Shared libraries: always up to date and synchronized<\/p>\n

Shared libraries allow several designers to start with the same base to begin their designs.<\/p>\n

They also allow us to streamline the work because if we update a component in the shared library, the modification will automatically take place across all the files of all the designers which used this component:<\/p>\n

\"\"<\/a>One change in the library automatically changes linked elements everywhere<\/p>\n

I have to admit that for the moment, of the various shared libraries I\u2019ve tested<\/a>, I have not yet found one which is totally adapted to work with Atomic Design\u2026 Still missing is this strong interdependence between atoms and components which allows us to create a lively and evolving system.<\/p>\n

Another issue is that we still have two different libraries: the designers\u2019 library and the developers\u2019 library\u2026 It is thus necessary to maintain both in parallel, which causes errors and requires a lot of additional work.<\/p>\n

My vision of the perfect shared library would be the following; a single library which would feed the designers and the developers at the same time:
\n
\n<\/a>\"a<\/a>My vision for the future: a single library which would feed both designers & developers<\/p>\n

It\u2019s when I see a plugin like React Sketch app<\/a> (recently launched by Airbnb) which promises coded components directly usable in our Sketch files, that I tell myself that maybe this future isn\u2019t so distant after all\u2026
\n\"React<\/a>React Sketch app plugin: coded components directly usable in Sketch<\/p>\n

Last words<\/h2>\n

I think you get it: I\u2019m convinced that we need to design our interfaces using components, thinking about lively and evolving systems<\/a>, and I think that the Atomic Design methodology will help us do it effectively.<\/p>\n

Audrey wrote this story to share knowledge and to help nurture the design community. All articles published on uxdesign.cc follow that same <\/em>philosophy<\/em><\/a>.<\/em><\/p>\n

This article was originally published on Audrey's Medium page<\/a>.<\/p>\n

Further reading:<\/h3>\n