Icons, done in the Design Tokens way

How can icons be implemented as Design Tokens?

Although they receive less attention when talking about Design Tokens, icon tokens can be very powerful.

Like any other type of token, icon tokens must be of level 1 and level 2, with level 3 being optional.

There are at least 2 key benefits worth mentioning when it comes to icon tokens:

1. More rigorous thought into the role of every icon.
2. More structured, scalable and maintainable icon set.

We will get back at those two in a second, for now, let’s understand how they work.

Imagine that we choose these icons for the product we are currently developing.

How would you name them?

I guess that at least some of you would pick their semantic/role/function, so: Home, Favourite/Like, Trash, Edit, and Notifications.

While this is not at all wrong, it is not the token way of doing it.

So let’s look at the first and second levels of Design Tokens:

1. Reference Tokens

Pick your weapons first, monsters come later.

This is where we establish our choices, E.g.:

• I choose this red #ff0044 and will call it “color.chills”.
• I choose Comic Sans and will call it “font.lovely”.

For icons:

• I choose this house and I will call it “icon.100”.

or

• I choose this house and I will call it “icon.house”.

Semantic vs Agnostic

As you can see there are two “schools*” for naming certain reference tokens such as colors or icons.

*In fact there are no such schools, I just wanted to give a more sophisticated touch to the two ways I often use to name reference icons.

The “semantic” school:

• I choose this house and I will call it “icon.house”.
• I choose this heart and I will call it “icon.heart”.
• I choose this trash can and I will call it “icon.trash-can”.
• I choose this pencil and I will call it “icon.pencil”.
• I choose this bell and I will call it “icon.bell”.

The “agnostic” school:

• I choose this house and I will call it “icon.100”.
• I choose this heart and I will call it “icon.120”.
• I choose this trash and I will call it “icon.155”.
• I choose this pencil and I will call it “icon.156”.
• I choose this bell and I will call it “icon.172”.

In my opinion, there are pros and cons to both approaches.

Pros and Cons

If “agnostic” is too abstract to communicate and memorize, “semantic” goes against the root agnosticism of reference tokens (AKA base tokens, primitives, global tokens).

Reference tokens are usually named “font-weight.100” or “space.400”. Naming colors and icons “color.blue” and “icon.house” wouldn’t fit into the taxonomy, would it?

While “icon.100” allows me to throw whatever icon inside, “icon.house” is 1000 times more intuitive to work with. Still, I prefer to use the first option, the “agnostic”. Here’s why:

I want my reference tokens to be empty boxes. Whatever I put inside should not shape the box. If I fill one of these boxes with a heart icon today, I want to be able to change it to a star tomorrow without any naming conflicts.

“Meaning” will start at the second level of tokens, the “system tokens”.

2. System Tokens

Here is where things get more interesting: The decisions.

By decisions I mean:

• I decide to use “rt.icon.house” or “rt.icon.100”(rt = reference tokens) as my icon for Home, so “st.icon.home” (st = system tokens).
• I decide to use “rt.icon.heart” or “rt.icon.120” as my icon for Favorite, so “st.icon.favorite”.
• I decide to use “rt.icon.trash-can” or “rt.icon.155” as my icon for Delete, so “st.icon.delete”.
• I decide to use “rt.icon.pencil” or “rt.icon.156” as my icon for Edit, so “st.icon.edit”.
• I decide to use “rt.icon.bell” or “rt.icon.182” as my icon for Notifications, so “st.icon.notifications”.

It is noticeably more easy to tell someone or memorize that the icon for “st.icon.settings” is “rt.icon.wrench” instead of “rt.icon.102”. Question is, how many times will I verbally pass a reference token to someone? Or how many times will I have to recall a reference token? I would guess, very few.

Chances are that what you will use to inform developers or other designers will be the system tokens, the decisions: “Hey John, please use st.icon.close for the modal”.

1. More rigorous thought into the role of every icon.

Now, back to my two main benefits, and after this little exercise, you can see that the choice and assignment of icons went through an extraordinarily precise and meticulous process.

Not only will you carefully choose the icons you want to include in your set, but you will also assign them a single semantic function and thereby reducing redundancy and inconsistency and leading to more efficient choices and decisions.

2. More structured, scalable, and maintainable icon set.

To explain this benefit, let’s recall some recurring situations:

Problem 1: You don’t like the cross icon and you want to replace it with a thinner one.

Solution: You open your reference token and replace/adjust the inner shape.

Result: All system tokens pointing at that reference token will now be updated, namely:

• Delete (for the action of deleting an element)
• Remove (for the action of removing an element)
• Close (for the action of closing an element).
• Error (together with an error message)

Problem 2: You want to change the delete icon from being a CROSS to a TRASH CAN.

Solution: You create a new reference token “icon.trash”, then update the system token “icon.delete” to target the new “icon.trash”. This will keep Remove, Close, and Error intact.

Result 1: Any component that uses “icon.delete” will now show a trash can.

As you can see, all this potential flexibility will come in handy at some point. On the other hand, the cost of upfront work is not significant.

To recap…

You can change one rt.icon and affect all system and component tokens targeting that icon. E.G. I change a heart icon to a star.

You can change one st.icon and affect all component tokens targeting that semantic element. E.G. The “favorite” is now represented by a star while the heart is used for “like”.

You can change one ct.icon and affect a very specific component only. E.G. The card component, in dark mode, will use a filled star instead of the outlined one, used in light mode, for “favorite”.

Figma Tokens

The Figma Tokens plugin has recently started to support “assets”. With it, you can easily store your logo, imagery, and iconography in a remote repository and link to it through the plugin. This will allow you to add an image to a shape in Figma with one click while ensuring that a living style guide informs its storage location.

Still, according to the Figma Tokens team, it might be too soon to use the feature since there is still work in progress:

“Currently the image source needs to have its own CORS (Cross-Origin Resource Sharing) validation. Some websites already have that implemented (e.g. Unsplash), but otherwise you can put this behind a CORS proxy. More information on CORS can be found here. We’ll be adding a CORS proxy in a future release.” Here’s the full article.