Hey! is there a reason you want the icon size to change? generally it is good to keep them consistent throughout your designs. Often Design systems might have a few set sizes (eg. for small, medium and large buttons) but for each of those sizes the icon size should remain consistent.

Your icons in your icon library should ideally be within frames that are all the same size. you can adjust the size of the icon within each frame so they look visually similar in size.

The icon library can all be one size, but you can adjust the icon size when you use it in the button component. (for example, a large button might have a 24pt icon, and a small button could have an 18pt icon)

When you use a button instance, you can swap the icon component and it should stay the same size.

Hope this helps?

Hey @Shuning , I had a similar question myself. I’ve been using @Ridd’s icon-wrapper method religiously for the past year and a half, but when variables came out I wondered if the method could be retired.

So far in my testing, I’ve found that the icon-wrapper method is still the best way to offer multiple icon sizes. I will likely write a longer more comprehensive blog post on this topic, I’ve seen this come up a lot since variables were released.

One note if you decide to use the icon wrapper method: pair it with the new component swap property for even better instance usability!

Hey @AlicePackard did you happen to experiment with the icon-wrapper method and nested instances in variants to have component properties overwrite the wrapper properties?

For example, i have a button with 2 states, which have different colors applied to. Inside my buttons i’m nesting an icon-wrapper with an instance swap applied to it. However when i’m instance swapping the color properties of the button states are not preserved.

The method im using works perfectly without the wrapper, but as soon as the wrapper is used the color properties are not overwritten as they are supposed to. This happens even if all the icons contain the same number of layers and are named “icon”. However if you go 3 layers into the nested instance, the names differ. Maybe that’s why it’s not overwriting properties.

Irina, I’m nearly a whole year late to replying! Apologies 🙏

I think your hunch about the differing layer names 3-layers-deep is correct. I’ve been doing more testing with icon color override preservation, specifically with shape building actions, and it seems identical layer names are more consequential than identical layer structure.

I need to document this better somewhere, in a blog post or perhaps a video, but I’d be interested to hear what changes you’ve made or solutions you’ve arrived at in the 11 months since your reply!