Design Systems for prototypes

A Figma experiment to practice consistency for UI components and quit designing tangled prototypes for all interaction states.

At SZ we work heavily with Figma Libraries. It’s easy to design with them, it keeps things in order and, let’s say it, it is also a bit of a guilty pleasure for designers to maintain them.

Recently I experimented with the BETA feature for Interactive Variants. This started a chain reaction that brought me to redesign the library for my project completely. Now I got more complexity (oops), but I can create prototypes that are smarter and easier to maintain (yuhuu!!).

This is how I did it.

The Dream

My poor Figma prototypes had been suffering for months under the common sickness of connection overload. This sickness manifest itself with an increased amount of prototype connections that fly around one’s Figma file, apparently with no logic whatsoever.

Obviously not a good prototype

When Figma announced interactive variants, I finally saw the possibility to redeem my crazy prototypes and stop building all screens for components interactions. I was eager to try it out.

What I wanted to do

The editor-facing CMS interface I design, was perfect to try out the new feature.

My goals at that time were:

• Build reusable components that can switch automatically between different states depending on the interaction of the user
• Have an overview page in Figma with all components and state so that engineers could refer to it easily

My colours, icons and typography were already in place. I could start directly with the UI components.

As you normally do as a designer, I started with buttons. :)

Primary buttons were no issues, I was importing them directly from the general SZ library and didn’t need to refractor those. Secondary- and Link-buttons were another story: I had many status and a loose system to organise them; also a lot of written out Todos for components I didn’t create yet.

Doing it

I set out to group variants of the same symbol together and connect them as interactive components.

I put next to each variant an instance of the symbol so I could try it out directly in the preview and get an idea how it would have worked inside a “real” prototype.

This kind of interactive overview had potential, I wanted to make it so, that engineers in my team could use it as a reference when developing.

I decided to use always the same types of states across different components. I had a default, an hover, a focus and a disabled state, as well as a selected state for the components that required it. This helped me to spot places where my color concept was not working well. For example I wanted the disabled state to always work by giving a 50% opacity to the element. This showed me quite quickly that I needed to rework the colours of the icon buttons since with the opacity they were not visible on darker backgrounds.

All was well, but every time I was making these adjustments, I had to update all the variants manually.

So I decided to give every component a _master symbol and to derive all the variants from instances of that symbol. This was a lot of work at this point (I basically hat to redo most of the work), but then once done, I hcould make one change in one place and have it automatically be taken over by all the variants.

You can do crazy thing with this master/variant paradigm. The _master is where the layer structure is defined, the layout is set, and possible optional elements are already planned out.

Then you take the master, make a copy of it and set it again as component. This creates a nested symbol that can be used as a variant for a specific style.

Now that it is done…

I am quite happy with my library at the moment. Once I grooved into the process, then it was pretty straightforward for other components.

My prototypes got simpler because I no longer have to create a screen for all possible state combinations of my components. Also spontaneous prototypes of detail interface behaviour are becoming more and more easy since I basically only stuck ready-made components together, change the content and draw some connection links → Ready to go!

This prototype is quite high fidelity, with over states and interactions

Still, as you see the connection-mess has greatly improved ;)

What about you?

Do you have any tipps for improving Figma Design Libraries? Have you ever worked with many interactive variants? I look forward to hear from you in the comments ^^

Ciao!!