Rebuilding design components : Spacers & design tokens
In the past 3 months since I joined the current agency, one of my tasks was to rebuild a component library for an ongoing project in Figma.
Background
A few lines on the background — the previous designer used Sketch as the design tool but our team is transitioning to Figma. In the interim, there were no design screens in Figma to study or to work on. As an incoming designer having no access (yet) to any documentations and no design screens to follow up on the project, I bet you can imagine how annoying it could be.
I have never used Sketch, but learned about its limitations especially in Design-Dev handoff. It has no link but a file. In a meeting when my colleagues were talking about how to avoid uploading tons of screenshot design screens to Jira during design handoff, I was wondering, wait, what? why? After rounds of screen sharing, I started to understand the problem and had the urge to solve the designers’ problems.
The complications… the pain points
- Working as a UX/UI designer in an agency is not like working in-house, who may be lucky to have a well-established-and-maintained and tidy Design System to use. At the agency for this client, we have a “central library” maintained by another agency that our team only has the view right. Fair but inconvenient enough, we created our own internal and component libraries using the components in the “central library” to take some “control” back.
- The components to be migrated from Sketch to Figma have no variants. There are hundreds of standalone components without flexibility, ie. no auto layout or constraint.
- There are a bunch of design rules including the spacing guideline. Since the client’s product is responsive, there are 13 static spacers and 30 dynamic spacers for different breakpoints. Each spacer has a “code” ie. design token visibly inthe components.
- Instead of using the actual “px”, we are required to tell the engineers the exact token variables that represent the spacing in our designs.
- The spacers look like this, hard to notice the “px” value unless we click on it, and read the value on the right panel. Even though we created variants for all of them, it is still very hard to recognise.
I am a fan of auto-layout, especially when I can master the use of it. I am of the view that using auto-layout could achieve the same purpose to define spacings. Nonetheless, after studying how spacers can help maintain a higher consistency in a project/product, I should work flexibly and get used to the spacer method. However, when I saw the spacers above, there was again, a natural reluctance to use them.
I was told that we must show the token variables visibly in the design which was the way of communication during design-dev handoff, at least in the Sketch era. Yet, I was not 100% convinced and asked myself over and over again —
- I understand the involved engineers do not care about the actual px value but the token variable because it is a CSS class. Whenever there is a change in the spacer, they only have to change in the class. But still, do these variables exist to help engineers only but not the designers?
- Why can’t the involved engineers check the px value in “Inspect” and apply the token variables themselves? (hmm… it is an extra work, okay, fair enough)
- Are these just the standing guidelines for designers? After all, why is it mandatory to use exactly the same style?
- What if we as designers, were over-interpreting the importance of the variables to us?
- Why do we solve others’ problems but create problems for ourselves? Where did we go wrong?
Engineers are users, so are designers.
While the spacings are a standing guideline that the chance of frequent change is unlikely, why don’t we rebuild the spacer components which are convenient to use for both?
Final solution
I imagined myself as designer (DS), and my users are the designers and engineers. I decided to put the token variables AND the px value visibly in the spacer components. Then, I created 3 sets of variants for the dynamic spacers to be used in different breakpoints (Property 1), so that the px property (Property 2) will not be mixed in all variants, ie. when I choose “000”, there are 10 variants instead of 30. After all, we want to pick the right spacers for the respective breakpoints. In the case, the engineers do not need the develop the component because what they need is just the token variables being visible.
I hope my fellow designers will like the solution. What do you think about this solution?
Thanks for reading!
