While atomic design systems have been around for some time, it wasn’t until my third or fourth project that I became convinced enough of its usefulness to attempt to make one. After making my own design system, I quickly realized I would be wanting to reuse it on every project I worked on in the future. I then cleaned up my system, added some organization and made it into a template for myself and others to modify for whatever project or aesthetic they may need. This documentation’s main purposes are to explain how to use my template and to advocate for the benefits of atomic design.
When creating applications on any platform (VR, AR, mobile, web), I found myself running into a recurring problem. Namely, I would have an idea for the project and would go about implementing it without considering later iterations. This meant that when it came time to iterate the original idea I had, I was forced to undo a lot of the work I had already done. This created a huge sunken cost that I needed to consider every time a change was needed.
To prevent sunken costs on future projects, I began research to determine which UX best practices could promote efficiency. I quickly found that the most widely used method for efficient wireframe designs, was an atomic design system. With an atomic design system, the designers will create the smallest elements first, then use those basic elements to build other elements in a modular way until the final product is reached.
With the nature of the system, you only need to create the base from which every possible combination of elements, screens, and structure can be built off of. This means when you want to implement big changes, you will only need to tweak the building blocks, and those changes will propagate throughout the design. I was immediately intrigued by this and thus my senior capstone was born.
In my design, at the atomic level are elements such as fonts, colors, and icons. From these atoms I made components such as buttons and a basic Information Architecture (IA), which I consider the molecules. From the molecules I built out small components like authentication elements, popups, and cards, known as the organisms. From these organisms, I could finally build out entire screens, which solidified the ecosystem.
While the point of the design system is to serve as a template for infinite possibilities and not limit the designer by applying constraints for usage, it is still important to acknowledge the intended usage of the system. To use my system as it was designed there are the following steps to be followed:
Duplicate my template into your project folder
Adjust the atomic elements
Adjust the molecular components
Adjust the organisms
Prototype your ecosystem
Link the design system to a Figma ‘library’
Each step will include information about aesthetic, decision validation, tools to help you make similar decisions, theories regarding certain design elements, and some accessibility standards to keep in mind. All accessibility information will be derived from WCAG 2.0 which is recommended for you to review to ensure that your designs meet the needs of all users.
In order to begin using the template, the first step is to copy it into your project folder. Some important notes on this simple yet important step:
Create a project folder in Figma that will host all of your files for your project
Duplicate my design template
Rename it (removing KW Template)
Move it into the new folder you just created
The first step in the actual design is to start tweaking the most basic elements of your design: the atoms. When it comes to changes at the atomic level, it is very important to understand the aesthetic you are aiming for as the atoms have an effect on everything. This intended aesthetic can typically be found by researching similar styles that you like and compiling them in an inspiration board. From this you may start to see patterns such as:
Curved edges vs. hard edges
Warm colors vs cold colors
Playful vs serious
From these themes, you may begin to work on the atomic elements laid out in this section.
The first atomic element to discuss is font. The way the font library is set up in Figma is so that every single element inherits the font library’s styles, sizes, and family. In order to change these in the system, you’ll want to access and change them from the design tab. Figure 1 shows what the fonts look like when edited from the design tab.
The font hierarchy is currently set to represent all possible use cases of fonts in an application. This ranges from titles to input field text and more. If however, through production, you find that there are use cases that have been omitted, it is important to add them in. Figure 2 shows the current font hierarchy.
One way to assist in your decision for font sizes is to follow a type scale. For the font system in place, I have followed an Augmented Fourth type scale. Scaling systems work by taking a base font size and then using a multiple to create all other sizes. A helpful tool for creating a consistent scaling is Type Scale. Figure 3 shows an example in Augmented Fourth and a 16px base. After generating the type scale, you’ll want to make sure to only use the generated font sizes in your hierarchy.
Another important aspect to remember when implementing fonts is how important hierarchy is when considering accessibility. This is covered in greater detail in a later section of this documentation, "Molecular Components".
Another atom in the design system is your color library. To work on your color library, you’ll want a basic understanding of color theory. Color Theory is a wide topic that can be covered in greater detail on Color Matters. For our purposes, color deals with three main aspects:
The color wheel: explains how all colors originate from the 3 primary colors which combine to make secondary colors, then tertiary, and so forth until you have the entire visible color spectrum.
Color Harmony: When pairing colors together and using multiple colors on a page or element, you want to achieve a harmony. This would mean that the colors balance well and according to Color Matters, “Color harmony delivers visual interest and a sense of order.”
Color Context: Some colors have meaning that is associated with our human perception of certain hues. In much of the world, we associate reds with danger, yellow as a warning, and green as a positive or a ‘Go’. This could be due to red’s association with drama, yellows association with awareness, and green’s association with calmness (nature). Each color has its own meaning and its important to attempt to understand these meanings in order to use a color that best matches your intention.
In Figure 7 is the color library that I have used in my template.
As a part of understanding color theory, we must also understand different people’s perception of color. Not everyone sees the same color as we do and as a result, certain color combinations create very hard to read text. This is important to address if you want to make your application accessible. A handy site for ensuring color contrast that meets WCAG 2.0 accessibility standards is Web Aim. Shown in Figure 4, this site allows you to check 2 colors against one another and only use them if they have an acceptable Contrast Ratio (the higher the better). In the example seen in Figure 4, I used my primary color (#90359) and my fourth color (#FFF591). The resulting contrast of 7.62:1 is high enough to pass all instances. With this in mind the most common color combinations in the current template library would be:
White on primary, contrast of 8.55:1
White on secondary, contrast of 5.94:1
Fourth on primary, contrast of 7.62:1
Fourth on secondary, contrast of 5.29:1
Third on primary, contrast of 6.76:1
Third on secondary, contrast of 4.7:1
When it comes to using or adjusting the colors in the design template, be sure to edit them only in the design tab since, like the fonts, they are inherited everywhere else. By changing it in the design tab, you are ensuring that the styling is propagated across the system. Figure 5 shows how to use the design tab to edit colors.
With both fonts and colors in place, the app will begin taking its shape. The next important component to make at the atomic level is your iconography. For this design template I have crafted an entire icon library that I hope will cover all possible use cases of any application design/development. If it becomes apparent that there are additional use cases, then icons should be added (much like with fonts).
For the design of the icons, I aimed to create simple vectors that could represent their targeted purpose. I went with minimal curved lines, sticking mostly to sharp corners, and used a mix of fill vs outlines. All icons have variants that include all the system’s colors. All icons are exportable as .svg. All icons were made in the rang of 10-20 pixels. Not all icons are symmetrical (e.g. 15x15) however they all were given dimensions that create balance.
The use of the icons will vary based on the application you are creating. Some icons can help balance out a word-heavy page. Other times, the icon will fail to accurately represent its purpose and words or a button will need to be used instead. For example, a trash can be used pretty universally to represent a delete functionality. However the use of the edit icon might be misunderstood if there are varying elements that could be edited on a screen and placing it next to one element may make it appear as though that is the only editable component. Proper use of the icons can typically be verified in user testing if you can capture how the user expects the icon to behave/represent, compared to what it actually does.
After decisions have been made and validated on the atomic level, it's time to move on to the molecular components. This is where individuality can be expressed in the application design as you are taking common elements (fonts/colors) and combining them in ways that have possibly never been done before. For the molecular components, I chose to go with a slightly softer design (rounded edges and more curves) while still maintaining the hardness that is present in both the font and the icons.
When designing buttons, it's important to follow all the same accessibility standards that we have discussed so far. It is advisable to only pick a few different button designs and reuse those throughout the application to create some familiarity and consistency across varied elements. After picking a couple of basic button designs, you’ll want to create variations for the different button states. Some common states are going to be:
In addition, you’ll also want to be cognizant of your device type. For example, on desktop, it's common to have buttons that take up a small amount of the parent container. However, on mobile, it's common for the button to take up the width of a container. This is due to screen size and readability. In addition, when making applications with these buttons, you’ll want to take into account accessibility standards such as focus and navigation that make the button usable on screen readers and other assistive devices. Figure 6 shows my design system’s template buttons. My template buttons followed 3 different designs. First there is the basic button which includes text for the action. The next button includes the text as well as a small icon to further prompt the action. Finally, the third button is only an icon that prompts an action. All of these buttons are in both primary and secondary colors with variations between un-clicked, clicked, and a disabled action.
Navigation bars are an integral part of almost any interactive application. They provide a base for moving through the application and can make navigation really hard or really easy for the user. The design that is used in this template uses a small amount of text with a few icons to create a simple navigation header and occasional navigation footer. It is highly advisable to spend extra time on this molecular component as this is where applications will vary the most from one to the next. Figure 8 shows navigation on mobile headers and footers.
Inputs followed a similar design as the buttons and navigation in that they are softer than other elements. They use rounded edges and lighter fonts to prompt the user to fill in the input. With the inputs, I created one variant that included a strong prompt above the input, and one that didn’t. This was done to encompass the different use cases that inputs have. These inputs can be seen in Figure 10. For the inputs I created:
Long text input
Short text input
Information Architecture (IA)
Another important molecule to design at this stage is the Information Architecture. When creating an application there are going to be many instances of displaying information to the user. This information should be displayed in a hierarchy with relevant information grouped together and lead with an appropriate header. Some examples of the IA template I made are seen in Figure 11. It's also important to remember that IA is about more than just aesthetic, it also plays heavily into accessibility standards.
In WCAG 2.0 guidelines, multiple success criterion rely on proper use of Information Architecture (IA). IA describes how an application’s information is laid out based on certain information being more important than other information. In web applications, this is typically accomplished through the use of tags such as <h1>, <p> or <small>. When used properly, the site is very operable for screen readers and other assistive devices. When used incorrectly, a site can become impossible to use with assistive technology. To meet these criteria, I have listed a description of what each font style tag should be used for as well as how they should be used. While this is a part of the template that can be adjusted, be sure that upon adjusting, WCAG 2.0 guidelines are still being considered. The use cases of the font hierarchy can be outlined as follows:
<h1> Title: This should only be used once on a page and is meant to represent important information such as the title of the page.
<h2> Subtitle: This should also only be used once and is supposed to provide supplementary implementation to the h1
<h3> Main Heading: This can be used multiple times on a page but should only be used to describe unique and somewhat important groups of information.
<h4> Secondary Heading: This can be used more freely to group any related information underneath a single header
<p> Large Body, Regular Body, Small Body: These can be used in combination with an attribute to alter the size, however, should not vary in the importance of information and sizing should be used simply as an aesthetic to keep spaces balanced and not overcrowded.
<button> & ‘font-weight’ All button text should be inside of the button tag. Even though the button has a heavier font weight, its important not to use the <strong> tag for the boldness because the boldness doesn’t represent a more weighted importance, it is simply used to fill the button in a balanced way.
<p> & ‘font-weight’ Card Header, Small Header: These should be used as headers of information with similar font-weight rules as the button
<a> Link Text: should be used for any links
<small> Fine Print: should be used for any small labels of information
<strong> Should only be used if the bolded word is being used in the middle of other text and the bold is attempting to emphasize that word’s importance. It should not be used as an aesthetic. This bullet gives an example of when <strong> can be used to denote importance through the use of ‘not’.
<br> As a note, br should rarely be used to create whitespace. Whenever possible, try to replace a <br> with 2 <p> tags and give the <p> tags the necessary padding and margin
Like with all aspects of the design system, if it is discovered while using it that some components are missing, it is essential to add them in so that over time your version of the template can cover all use cases of a digital application. Listed here are some extras that serve very specific use cases that have been included in addition to common components.
Figure 12 shows a progress bar that was discovered as a need during the creation of one of my projects. This component could be reused anywhere that a progress bar is necessary.
After building out the molecules, many of them can be used directly on the screen. Some molecules however can be combined in order to create organisms which are slightly more complex. Similar to some molecules, organisms can also be built out in a way that they can be place directly on the screen. One important thing to note about organisms is that because they are so close to being the application itself, that a lot of filler text needs to be used for them to make sense. It's important to remember that not all of the fields have to be populated the way that they are in the template. Depending on use, some molecular components may need to get stripped from the organism to better fulfill its purpose.
Informative Cards and Pop-ups
One of the components I see used most on digital applications are cards and pop ups. These can do anything from supply the user with information about what they’re doing, to giving them an action to perform in order to advance in navigation. All of my template cards follow the softer design of rounded edges, and lightly colored lines that separate the content on the card/pop-up. Some key templates I made for this were:
Cards which are brief callouts of information with quick action items. These can often be found in settings or next to more confusing and complex organisms. These are seen on the left of Figure 14.
Informative pop-ups that are dense with information that the user intentionally clicks on to view more information on something that was displayed more briefly or as a summary prior to clicking on it. For example if someone clicked the informative ‘i’ icon, they might see one of these pop-ups. These can contain details such as media, nested organisms, statuses, or lists. They all have headers and a way to ‘escape’ or return back to what the user was doing previously. These are seen in the middle of Figure 14.
Informative pop-ups that appear during navigation. These could ask the user to stop and consider something before committing an action or help guide a user to another area. These are seen on the right of Figure 14.
When building out your design system from this template, its advisable to give these some uniqueness as most of them are likely to appear on your application.
Something that can be found on almost every single digital application that exists today, is authentication. While it is difficult to show in the design template, it's worth noting how important good security practices are for good UX. One of the main goals of UX is to give the user a good experience on your application. One way to grant this experience is to build trust with the user. Trust can be gained and destroyed in the authentication process which makes good security extremely vital in achieving good UX. Together, security and accessibility are two musts if when creating ethical products. In regards to what is visually viewable int the design system, I have included:
A sign up form with an associated action for if the user already has an account. This is seen on the left of Figure 15.
A sign in form with an associated action for if the user does not yet have an account. This is seen in the middle of Figure 15.
A box for confirming your email after signing up. This is seen on the right of Figure 15.
Last but not least, is the creation of some template screens on your application’s design. Because the final ecosystem and combination of organisms is going to be extremely unique to your application, I won’t go over each screen individually. However, the screens do provide a great analysis of the design system atomic structure. In some screens for example those in Figure 16 and Figure 19, you can see how these pages are mostly just a reuse of molecules without much original structure or design going into it. However, on other screens such as Figure 18, you can see that while the atomic and molecular levels were used, there were no existing organisms that could be applied to the screen. This highlights the importance of knowing your system. When you understand your system from the top down, it is easy to think up a page because only certain aesthetics will fit your design. Another thing that will come in handy when using a design system is seen in Figure 20. Here, there is a blank mobile screen which can be used as a background for any other screen design. Having a frame in Figma that actually looks like an iPhone is important because once you’ve reached the ecosystem phase, you are no longer creating elements, but full fledged screens. You want to start envisioning the final product as it will look on your phone in your hand and a mock phone screen makes that imagination easier.
Now that you have built out the design system to the aesthetic you are hoping to achieve, you want to be able to use it in an efficient way that takes full advantage of Figma’s built-in tools. This is where linking your design system to a library comes in handy. To achieve this you will want to follow these steps:
From the page’s dropdown, select ‘Publish styles and components’ (you will need at least an educational plan to use this feature. Educational plans are free for teachers and students)
You will see a list of changes which should include every single thing you’ve made since this is your first time publishing. You can add a description such as ‘1st Commit’
Head over to your other project where you want to use the design system.
In the Assets tab, select the open book to access library options
Now you can toggle which libraries you want to use in the current wireframe you are developing
You will now see your design system in your assets panel with all the assets able to be used in your current wireframe
Steps for updating your library:
Return to your design system
Make your necessary changes
Once again select the page title dropdown in order to ‘publish’ your changes
Return to your wireframe project
Select the library icon
Go to the updates tag
Select ‘Update All’
Overall, having a design system can serve as a convenience which will save you tons of time, and in some cases money. It is important to always take the time to start at the atomic level and build up from there in order to not only create components that make sense but to also make sure you firmly understand the aesthetic you have developed. The benefits of having a modular design system outweigh what may feel like tedious work when starting out. With a properly thought out design system, iterations will be quicker, and aesthetics will be better tied to one another.