You need to sign up for the Interactive Components Beta program to start experimenting with this new feature as it is not yet available in the current stable release. Now, before we start: Interactive Components (Beta Access)
Figma interactive components how to#
Using Interactive Components simplifies not only the final prototype but also the logic behind it, making it easier to learn how to build, maintain and update the prototypes. In the next example, it only requires one screen and one component with two variants for the interactions, and the switch is the same so it can be duplicated as many times as needed: And if I wanted to use three switches, I would have to add even more screens and interactions. Here’s a comparison example of how the workflow will change:Īs you can see in the example above, it requires four screens and eight interactions to make the prototype work as a real product. This means that it is now possible to create a component with states (hover, active, clicked, focus) and make it interactive so that every copy of the component will inherit those same interactions by default, helping a lot in the prototyping phase. Pressing a key changes the Component's Variant to match the key that you've pressed.Recently, Figma rolled out the beta for the newest interactive components feature that allows defining interactions and animations directly into the variants and propagates them to every component instance. The input field is a row of 26 of these components. Without the ability to store, refer to, or manipulate actual data like text, numbers, or values, designers will be limited to what can be fully represented through snapshots.įor example, Design XStream's text input has a "Single Letter" Component with Variants for each possible character. While Figma's Interactive Components do expand the field of what a designer can do in a Figma prototype, there are still some major limitations. Prototypes that were impossible (or impractical) before are now comparitively easy to put together. However, by pushing the problem down into Components, Interactive Components greatly reduces the number of combinations. The fundamental problem hasn't changed: modeling a Component with multiple properties still means creating different Variants for each combination of the Component's properties.
The solution? Create a Frame for every possible state combination. This meant that a designer looking to model other types of state, such as whether the user is in a "light mode" or "dark mode", would have to somehow achieve this complexity with only that single property to work with. An app's state might also hold information such as the current user's name, their preferences and settings, or the contents of their shopping cart.īy comparison, a Figma prototype's state included one piece of information: the user's current Frame. Navigation is often only a small part of that state. Real apps keep track of lots of information that describes the current "state" of the app. There were some tricks to reduce the number of links, such as using the "Back" transition target or setting your links on a Component and then reusing that Component between Frames, but there was really no escaping it: prototyping in Figma meant drawing lots and lots of arrows.Īnd while I really like drawing arrows, needing to draw so many arrows made it extremely tedious to prototype even a medium-sized project in Figma.
0 kommentar(er)
