The core foundations of atomic design
A month ago or so, I got invited to have a short lecture at Ironhack Berlin as a part of Atomic Design class, meant for students who have no or minimal background in designing for UI. This was as an opening lecture to kick off the journey into building components and eventually Design System libraries. I took this opportunity to talk about Core Foundations, a subject that I personally wished someone would share with me before I ever made my first UI element.
Core Foundations are not only the brick-and-mortar of a user interface design, but they also form a first and the most important bridge, linking developers and designers together, giving them a shared vocabulary before any line of code is written or before any pixel is drawn.
This lecture was structured to cover the basic principles of Core Foundations with high-level examples. I decided to publish it here, with some minor updates and changes, for anyone who is taking the first steps towards user interface design.
Why?
Before diving into building blocks of Core Foundations, we have to understand why we need them.
I like to use our universe as an example, where there is an enormous amount of complexity and versatility in coexistence. Still, all of the essential building blocks that form the planets, galaxies, people, etc., are following a fixed set of physical laws.
In short, Core Foundations are equivalent to physical laws in nature. They are a set of rules that define everything that we see and experience in UI.
What?
There are essentially four pillars of Core Foundations that are required to form a modern UI for a digital product:
- Color System
- Spacing System
- Typographic Scale
- Animation & Haptic
How?
In this article, I will only cover the very basics for the Spacing System and Typographic Scale and spend a little more time on how to set up a Color System, being the most noticeable part of UI, which also happens to be the most emotionally connected to stakeholders. I will skip the Animation & Haptic as it’s not as vital as the others.
If there was one thing that I would want students to take away from this lecture, is that constraints are your friend.
When options are limited, people generate more, rather than less, varied solutions because their attention is less scattered.
In the case of the Color System, constraints are applied at the very beginning, when assigning a function to color in the form of a category under which each color will exist.
Instead of using vague names for colors such as “Millennial Pink” or “Palm Green” we should use terms like“Transaction”, “Warning” to instantly define, on a high-level, what the role of this colour is.
Color, just like any other element in the UI has to serve a function and with that compete for the user’s attention. Be clear and articulated when deciding what color should justify its existence in the UI.
You must align with the brand beforehand, as they approach colors differently than a product, they might come with suggestions that have no functional application in UI.
Defining a role or a function at the beginning can prevent arbitrary use of color that usually contributes to a snowball effect which results in Tech / Design Debt.
Each color comes with its own color family — a scale of shades going from dark to bright:
Having this available at all times allows us to scale and adjust our values for a more specific use.
Here is an example of selected values from the Transaction’s color family that will be used in the final palette and will cover basic button states:
If there is a need in the future to increase or decrease contrast, you can always come back to the color family and pick lighter or darker values accordingly.
Another example of using constraints early on is by using the color matrix, which in the end forms a final palette.
Each color category can have any amount of different colors, predisposing that each one of them has a clearly defined function which is indicated in its name. For each color there is a fixed brightness scale of 5 values:
And this is how it looks when we apply a name and required values:
As you can see we left two values at the top and bottom part of the scale empty. That is perfectly okay as you should only use the values that you need and keep the rest empty for any potential future scaling.
Setup like this allow us to form a really simple naming convention for Sketch layer styles that can also be mirrored in frontend:
Transaction — Light (Color Name — Level Name).
A complete color matrix forms our final color palette:
Accessibility is a subject that demands it’s own lecture, and I am nowhere near experienced enough to talk about it in any greater depth. However, I use it as a way of combining color pairs and accordingly adjusting palette values.
Using our Warning color as an example, we can see that if we apply default white text over it, we get a really low contrast ratio between the background and a foreground values:
For now, the important thing to remember is to aim for AA level which is any contrast ratio above 4.5. You can use this tool to see what the ratio is.
If we, for example, select our Layout — Regular color, we can see that a ratio goes well beyond 4.5 and is then used as a text color in combination with Warning background color:
In case our Layout — Regular would fall under 4.5, let say 3.9, we can either pick a darker level from a palette or slightly adjust the regular level to reach the target ratio. This is how we can systematically define color pairs.
Unlike the Color System, Spacing System is quite straightforward. We need to agree on values that will form spaces between elements and sizes of individual components. This also includes breakpoints for different viewports.
8pt grid is the industry standard way of defining those values since most of the popular screens are divisible by eight on at least one axis:
This means that we use either multiples or divisors of 8 as spacing units. Here is an example of spacing units that follow the 8pt grid:
Visit this link for more details about 8pt grid.
Same logic can be used for breakpoints. In this example, all the gutters have fixed width of 16px with content size being divisible by 8. This is how we ensure that components naturally fit in to the layout.
With the Typographic scale, I will only highlight the importance of having one that avoids the usual pitfalls that happen as a result of unplanned and arbitrary changes.
On the example below, we have a scale on the left that has too many similar values and no clear logic on where and how they should be used. There are also too many different typefaces, which might burden the performance among other things.
Final Points
I believe that good relationships trump even the most logical and clearly defined rules and guidelines. That is why Product Designers need to work with developers from the beginning.
Understanding each other’s work will not only make both sides more efficient but also aware of constraints and differences that are sometimes left in the blind spot.
One way how to establish a strong relationship is to share work early on. The best, yet one of the most uncomfortable things that you can do as a Junior Product Designer is to expose your early ideas with developers and ask for them to point at the potential bottlenecks when it comes to technical implementation.
You might get feedback that isn’t really constructive for a problem-solving part of your solution, you might also get technical feedback that will help you save time later on.
In any case, you will send a clear message to developers that you respect and value their work and are willing to help row the same boat against the current.
Rowing against the current might mean many things in the future. For example, convincing stakeholders that the company needs a design system. With the developer community inside your organisation backing you up, you will drastically increase the chances of success than doing it alone or with a couple of fellow designers. The same can be applied for the Product Owners.
So share early and win the hearts and minds of fellow devs and PO’s.
Thanks for reading.
