Button Variants best practice

Ask the community
1

I’m working on a project with many different types of buttons.

I’ve decided to build the many variants by basing them on a Main/Master component.
The Main/Master component has variants itself and holds all the information regarding shape, size and icon placement.
The Child Variants hold the different states, colors overrides for primary and secondary, wether there’s an icon or not, etc.

In the design, those buttons sometimes need to hug their content sometimes be full-bleed and fill their parent container. For the same button, sometimes the label should be centered and sometimes aligned left/right.
Is it best to create variants for hug content and fill container plus the L/C/R alignements? or is it best to set all buttons in the variants to hug content and apply auto-layout overrides in the design?

I’m afraid that creating all options will become very cumbersome to maintain over time and would like to know what’s the best practice for such use-cases.

2

Hi, I would think about how do you want it to be coded. Instance overrides are equivalent of HTML inline CSS in web dev. There are rare occasions in which a developer wants to use inline HTML (see under When to Use Inline Styles). Consider that, if it’s cumbersome to maintain over time for you, it will be also for your developer.
But, if L/C/R modifications are smaller rare occasional overrides, then these may take place inline or in your case as auto-layout overrides. As best practice, you should avoid these, and instead you may try to rethink you design decisions and simplify cases, reducing them to fewer states.

1 Like
3

Thank you for your input this makes a lot more sense now.

I’m porting a design to Figma and building its design system along the way. So trying to make do with what was there and making it more streamlined.

4

Hi @h_v_b ,
I have the same problem with the size of the button - hug content vs full bleed when working with master components.
Couldn’t solve it so far but don’t want to duplicate the number of buttons just for that purpose.
Have you found another way to solve the issue?

5

I also ended up doubling the button components (hugged and full-bleed).

They are both children of the same master component (which holds all options), but with different auto-layout constraints applied or visibilities. It is a bit cumbersome to make, but very easy to use in designs in the end and to maintain.

6

Thanks for the quick reply! I guess there is no other way then :frowning:
You might be right in terms of low maintenance costs but just a pitty that working with master components isn’t a little bit more flexible.
thx st