May 29, 2020

Writing a Bachelor Thesis - Weeks Five and Six

This note is part of a series, to learn more you can read the previous note in this series or jump to my bachelor thesis exposé.

From re-designing Atomic Design to re-interpreting Atomic Design to designing for Atomic Design

When I started working on this problem, I thought my goal was to change what Atomic Design is. As it turns out, Atomic Design isn't the cause of the problems issues I observed. To recap, the problems I originally wanted to solve were:

  1. Linking visual design changes between atoms
  2. Mapping Design to code to reduce the workload when implementing components

Problem one – linking atoms

I was able to confirm this is of interest to my target audience. During the research phase, I discovered all of the interviewees attempt to solve this problem for multiple motivations. They all succeed partially by the use of design tokens. Some specific kinds of tokens, however, present challenges that currently aren't solved by design tools such as Sketch or Adobe XD.

Another problem was the naming inconsistency: Some call tokens sub-atomic particles, some call them an interactive style guide. A design token is a single style-rule, such as the color of a link or the base-size of text. It is implemented as a reusable object in a library file, as a layer-style or as a text-style. As Atomic Design is also used as a way to find a common terminology, the disambiguation to this inconsistency will have to be part of the solution.

When I asked why atoms should be linked in interviews, I generally get an answer containing two motivations: consistency and flexibility. The goal is not to have to manually edit all atoms to apply changes made to one aspect of one atom. To achieve this, all Atoms must be constructed from tokens, leading to an effective linkage between Atoms.

Example: Assuming the atoms are constructed using tokens, changing the outline of a text-input field will also change the outline for all checkboxes, radio-buttons, and ghost-buttons.

Problem: When constructing a button, you drag in the token for shape and a token for text. You apply your token for a button-fill-colour to the shape, and you now have a button that changes appearance when you change, for example, the shape-token.

You can even use smart-layout features to have this button change width when you edit the button text. But there is a catch: if you change the token for text size, your button won't update.

What you are looking at is a button instance on an artboard in Sketch (left), a button symbol constructed from a text and a button-shape token (middle), and the button-shape token (right). In the beginning, the border-radius property of the button-shape token is edited, immediately altering the button symbol and the instance of the button. Next, the text size is changed, which neither updates the button symbol, nor the button instance.

If you change the text size in CSS, this isn't a problem. You can try it by editing this example on Ccodepen. Simply change the second to last line in the CSS field from 2rem to 3rem or any other size value. The preview will update in realtime.

See the Pen Button Example by Wenzel Massag (@unknwntrr) on CodePen.


While the remainder of problem one will likely be solved by design software such as Sketch and Adobe UX in the near future, the second problem is a more difficult nut to crack.

Problem two – mapping design to code

By mapping design to code, I meant the problem of linking a property, such as the font size of a button, with it's counterpart code-block[^A code-block is a set of instructions in a programming language.]. After the interview process this problem statement has gained a new meaning in my mind:

Designing in such a way, your designs can be easily implemented in code.

This requires the designers designing design system components to have fundamental knowledge of code. This notion of designers having to know code to some extend isn't a new one, but it remains controversial. According to all of the interviewees, five out of six being designers and only one of them being a software engineer, designers need to gain a fundamental understanding of code. And considering the nature of their work, it only makes sense to understand the material their product is going to be made out of: code.

A fashion designer needs to be able to sew, they don't need to understand how to mass produce clothing. A digital designer needs to understand how to code, they don't need to be able to implement their designs as scalable software solutions.

As such, this second problem has morphed into a new problem statement: Designing for Atomic Design.