Wise rebrand

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 Team

Design Lead

Ness Grixti — Me

iOS Development

Daniel Tombor,

Android Development

Joao Cevada

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


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.


We created a foundational static set with token names that were scaleable and explicit, allowing us greater control of the system.


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.


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.


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.