Spacing library overhaul
I recently was tasked to re-review our spacing system for accessibility. As part of the rebrand that launched in March, 2023, we had looked at a system for spacing. But, post release we found it was riddled with issues causing inconsistencies across product.
With the release of Figma variables, it was prime time for me to fix these issues and improve the accessibility of our system even further.
You can see the live documentation on spacing at wise.design.
The Process
01 Audit
As part of the audit for spacing, I looked at spacing between elements across our templates and in-product experiences as well as padding within our components and patterns.
I also reviewed the existing system and spoke with designers on their experience with the current setup.
Key findings
Confusing
Poor naming and no variables. Heavy reliance on the guidance site and constant scrolling to find what size extra extra extra small is.
Poor foundations
While t-shirt sizes are better than abstract names, they don’t scale or tell you anything about the value.
Not a11y friendly
Our spacing system didn’t scale, leading to poor proximity between elements when scaled.
Poorly built
We had built in spacing on some of our components. This causes issues at scale, as there is no one size fits all.
02 Alignment
Post audit I had found a number of inconsistencies which needed to systemise before we moved forward.
Creating consistent rules
Across the audit I found multiple places where we had misaligned rules across our own templates — no wonder everyone else was confused too.
By doing this I was able to align all of our global spacing rules.
Grouping by size then type
As part of the alignment I looked at different spacing types, first grouped by size, then by usage.
This gave me a better idea of potential semantic tokens and usage rules.
03 Scaling
Creating greater proximity at scale
Wise support native platforms, which allow for dynamic scaling for accessibility. As part of this work we wanted to ensure our spacing scaled with our text, creating better proximity between sections.
When to scale
Scaling is defined on when it would have the greatest impact on proximity in product, all of our vertical tokens scale, whereas only the only horizontal tokens that scale are for elements that scroll off the screen.
04 Semantics
Creating a useable set
Based on the audit I had identified a few key scenarios that were more common within product experiences.
Testing our styles
To test our styles I created a game called name that space, where I asked people to match the space name to the space across various UIs.
This allowed me to identify patterns and clearly identify what names were and weren’t working.
05 Build
As we had opted to use foundational and scaled sizes within our own system for component padding. So I linked all of our components to our foundational and scaled sizes based on our scaling rules.
Foundations
We created a foundational static set with token names that were scaleable and explicit, allowing us greater control of the system.
Scaled
We then created scaled tokens using a % based model.
In Figma we used modes to define these with variables. With 100% referencing the foundational value.
Semantics
I then created a separate library public library for our designers to use with our semantic values and updated all of our templates with them.
The results
Semantic naming
We created semantic tokens for our most common spacing values across product so designers and engineers didn’t need to guess when to use what.
Solid foundations
We ditched the t-shirt sizes and called our values what they are, making them easier to identify and scale.
Accessible
We implemented a scaling system that allowed spaces to grow with text, creating stronger proximity between elements.
Variable tokens
We removed our built in spacing and implemented semantic variables reducing reliance on guidance.