Being in software engineering, I find this impressive and not complicated. However, I can see how it confuses non engineer background designers from reading comments here. I’d say, Don’t fret the confusion folks. Honestly, this is a huge, positive feature to the platform. It’s going to make the designers life easier and the developers life easier in the long run. If you take a step back and think of it from the users perspective on how the UI should change based off the interaction, you’ll then be able to easily apply that to the prototype without being confused by all these words like “variables” , “booleans”, etc. Just think of the user interaction and trust your design abilities and this is going to be a massive productivity and highly interactive boost to your design workflows.
It is fascinating to see how Figma encourages designers to get more involve in adding logic to their design components. Not only does this make handoff to developers a breeze but motivates designers to think and really understand their designs, and how it needs to function for the platform their designing for.
Hey! I use Axure 8 yet too, as it's a lifetime license! And it works well until now! And the conditionals are much easier than Figma, as I watched this video. And it has way more options to do than Figma. But it's good to have those functionallities in Figma too!
Considering this (and way, way more) has been possible in Axure for years and Figma has basically copied variables and conditionals directly from Axure, while this is great, I don't think it's "amazing". It's definitely a step in the right direction.
@@tofuComputer Considering Axure is an absolute pain to use while Figma is extremely accessible by new and seasoned designers, I'd say It's still amazing. You used to have to choose: Axure for prototyping or Figma for hi-fidelity easy designs. Now all you have to do is use Figma unless you need extremely high-level prototyping needs.
Love these advanced prototyping functionalities! Small nit - in case anyone's wondering - in this tutorial, I find the variable names for the basket/cart very confusing. Let's say on the World Peas website, we can add watermelons to our *Basket* by clicking on the "Add to basket" button. (Let's not call anything a "Cart" anymore - not in the UX copy, not in any of the variables/properties) Starting from 9:34, Our goal is to create an interaction like this: if you click on the "Add to basket" button, the appearance of the "Basket" button at the top updates to indicate that there is (at least) one *Item* in it. Calling the local variable "Has cart" and the Basket button property "hasCart" doesn't make sense to me. (You can't say "The basket has a _Cart_ "; you can only say "The basket has an _Item_ in it".) If you're watching this video and you're like "What does 'Has Cart' mean??", replace it in your mind with "has item", and maybe it will make sense :)
The terminology used is not directly relevant to the feature being demonstrated, but it's distracting and is just wrong. Seems like a painfully obvious fit & finish oversight in the demo project.
Really love the new Variables feature, it feels like a big step on the journey to bringing design and code closer. One small observation: binding visibility into a layer by right clicking on the visibility icon doesn't feel entirely intuitive. Right click always feels like a great go-to option but maybe not the first, most intuitive choice?
You can also make prototype mode semi responsive by creating a window variable and changing it's value on key press in prototype mode to change your designs width
OK we need a couple more things: 1. Component instance variables = values that live only inside an instance of a component, 2. onChange trigger on variables, and/or 3. toggling component variants based on logic on top of bound variable. Oh and 4., we need this on instances nested in other symbols, not just standalone instances. Example use case: Want to create tabs. Need numeric instance variable activeTab storing index of active tab (alternatively string variable storing the label of active tab). Clicking individual tab in the tabs component changes the activeTab index to given number. (note all this is possible with "local variables", but would be needed on component level.). Final step: toggling individual tab variant based on activeTab value. Meaning if activeTab value changes from 2 to 3, tab no. 3 registers that activeTab == 3 and toggles its variant from default to active. At the same time, tab no. 2 needs to be observing changes to activeTab value, then finds out activeTab != 2 anymore, and toggles its variant from active to default.
I was right when I decided to choose UX design as my full time career after studying computer engineering! The line between design and development are going to be thinner and thinner going forward. It’s interesting on how prototyping has come along way. I remember how painful it was for me to iterate on my invision prototypes!
Looks a bit complicated but we'll see how it goes. For those saying that it's dev work and a designer doesn't need this level of complexity: I quite disagree. Realistic prototype is required for a proper user testing plus it helps tremendously to demonstrate how something should work. Remember that not everyone works on simple things like websites. My current project is a very complex market research platform with lots of calculations and interactions. A realistic prototype of a feature within it will help 1) the client to understand how the feature exactly works 2) me to check if the whole experience is intuitive, reasonable, and just good enough. That said, I agree with the comments that the way it's implemented doesn't look intuitive at first sight. For complex designs, it probably will be a bit of a headache
Is it me or this just seems overcomplicated in 99.99% of the design/prototype cases? You could just duplicate three or four screens and add all the interactions manually. You'll spent ten times less time doing this and the devs will catch the idea instantly. I mean if you make an interaction with 1 item available and 0 items available, with a full basket and a empty basket, any dev will understand the rules, styles and behaviour of the design/product. And I understand that this is a simple example, but even in complicated cases (I work daily on a huge app with thousands of screens and interactions) you can just divide the interactions or prototype and won't be a problem. I understand that if you want to create a extremely functional prototype that is a 1:1 version of the product, well... this makes sense, but in my honest opinion the vast majority of users won't be working with this kind of mentality. It is great that we have the possibility of course, but at the same time they're bloating the UI with dozens of icons, dropdowns, etc that mostly everyone won't use.
They could simplify the solution, in my opinion, by incorporating conditions directly into components as well, instead of assigning them with only with actions. For example, you can configure the component in such a way: if variable1 == true → change variant of this component into variant2 This approach would enable components to actively 'listen' for any changes in variables on a page, eliminating the need for creating lengthy, multi-level conditions. Or maybe there should be a conditions panel in the right hand side bar, and there you could set up all conditions you want.
I remember that day, when I tried figma for the first time. I have no idea what date it was. But I was quite early. And her dress was so nice. It was love from the first sight. And it just keep growing.
This is a stunning features for Figma and weak in terms of real programming. This difference makes Figma quite useless for business logic and UX designing (what the video actually illustrates), but may be useful for designing automation, simple prototyping, animation etc.
This is really cool - But I'm curious about how Figma handles the various screen variations during the handoff process for developers. Will they need to constantly run variables to see the different cases and screens? This is a new feature for Figma, but it's not for the industry. As an Axure user, I'm aware that Axure generates exported technical documentation that supports each variation, connections and interactions. Does Figma offer a similar feature? How will developers quantify their effort based on the screens? How will they become familiar with all the variations?
Its good but will it work with design system. When you already have a button variants and now again create another set of variants to perform these conditions and variables. Its just complicated the things.
How is the string variable (Cart Button Text) actually linked to the component variant? I don't understand how it could be linked to an unavailable button...
My team's component library includes prototyped components as part of our component file, which is published. Every design file which uses those components gets the built in interactions. How would I apply variant logic to different buttons within a design when the main component is located outside of the design file?
The fact that they correctly named it "Local Variables" for variables in the file gives me some hope that there are some plans for GLOBAL variables down in the road... :D
There's no way to apply a variable to a nested instance, right? I'm trying to create a "clear all" function for a dropdown menu, but the checkboxes I need to unmark are inside an instance. And "reset component state" doesn't reset variables. Sad.
This is an amazing, since The variable and boolean were initially made available by Figma. I was looking waiting for these upgrades in the prototype. Great update team. Awesome Job.
Amazing, but the tutorial file is full of ready variables and prototyping. I think the file shouldn't be editable for anyone until duplicated to his drafts.
Feel like this feature is an overkill. The amount of time you spent on this could have been used to simply communicate with your developer using 2 more screens. The feature assumes that the designer has strong logic and, in order to actually implement it, one needs to carefully consider where to apply it and how all the things are linked. With that being said, there are some advanced use cases for this for sure.
love this comment....its too complicated and it will not work with your design system, because you already have the button states and prototyping with variants now again you have to create another set of variants for this conditions. its not logically good.
I gave up coding to become a pure designer but looks like I'm going back there. 🤨What we design is not even a real product, the developers are the ones who bring things to life. Not sure if I should be doing prototyping to this extent on a design. This is a good addition to designers who no nothing about coding though. Also this reminds me of Axure. :)
Looks good. But does it actually replace Axure? We make a lot of prototypes where users can fill in form fields, then use those inputs to personalise the rest of the journey. Looks like that one last feature is yet to come...
I wish they would just support standard web components like radio buttons, input fields, and select menus. That would make the prototyping process so much more intuitive.
Not sure if that feature will succeed, even though I follow the great tutorial the functionality seems too complex. When it comes to prototyping there are less screens but a lot more complexity in the few that remain (more cognitive load for users)
Interesting update. Seems to go towards Axure while people switched to figma for it's simplicity. The entire variable concept seems unlikely to be used (maybe too soon to tell though) but replicating back-end conditions and logic simply doesn't seem to be needed. If figma does wanna get into nitty gritty realistic prototyping, a simply user text entry capability while previewing might go a longer way. Until it's embedded inside handoffs, it's usage remains gimmicky. There might be a use case of localisation/ language change at the press of a button which might be possible through this i guess, which might be useful
At 12:03, when you're updating the Cart Button Text variable to "Unavailable", you can also use the "Change to" option, to set it to be a different variant and achieve the same result (without setting up a whole new variable). Is there any benefit in doing it using a variable? This is definitely quicker. Using a variable is probably in line with how it is programmed, but that shouldn't matter while designing. Anyone?
I do the same thing about available variable, but when adding the instance card "unavailable" from the library, the instance itself turns into unavailable.
This looks fantastic. Although in reality how can anyone use this with the components one has on the design system? If I ascribe all these values to one button then this button is going to behave and change all of this element at the same time. For example if I want to use the button component on as the subscribe button then the cart button and available items will update? Is this method usable with design systems components?
Awesome. Just saved me from setting up a UX Pin paid account. What would be good is input widgets like input fields, selectors, etc and drag and drop components - - pleeeeeaasse?
When making the # of watermelons text disappear when it reaches 0, Is it better to create a second conditional on click like in the video or just move "set variable #is available to false" to under the else action in the first conditional (thus only having 1 conditional statement for the click interaction). It seems to work the same as the method used in the video.
We can create a boolean in a master component with the values 'yes/no,' 'true/false,' or 'on/off.' However, when using Booleans in variables, we must use 'true/false.' Hmm, not really consistent. I used to use 'on/off' because of the shorter words, but now I have to change if I want to use variables in the prototype.
sad to say we cannot practice variables and conditional in Starter plan on figma :( we need to buy a professional plan for this to practice this new updates
I understand the point of it.. But, it's too much (and complicated) for a few things that developers also can understand it without all this complicated stuff for designers... It seems like the steps are going to be "front-ending" the designers and there are also going to be companies that require that knowledge from you because they expect you to know it along with so many other things. And in the end you know everything but you are not specialized in anything. Maybe I'm going too far with this but this is what I'm perceiving. I design and try to communicate well with the developer. Nothing else. If it wasn't like that, I'd have made another career as a developer. There are already places where UX and UI go hand in hand when in essence they are different things. Should I also develop?
1) Create a local *number* variable called "total", and set its initial value to 0 2) In your prototype logic, when the "Add to cart" button is clicked (and as long as Amount available is still > 0), increase the value of the "total" variable by 3.99 (total = total + 3.99) 3) Add a new text layer inside the "Basket" button, with static text content "// $". Let's call this the "prefix" text layer. 4) Add another text layer right next to the prefix text layer. Let's call this the "total" text layer. 5) Bind the "total" text layer to the "total" variable Hope this helps!!
Took me a few run throughs to get this. The logic stuff is all fine but understanding how variables are bound to instances took a few goes. Simple now but wasn't all that intuitive.
As of now, I'm doing only landing pages. but if i get to use this, dang, i'll be able to use what i learned from my college degree IT. This set variable is easier to understand since i already have this knowledge flowchart and if/else.
Does anyone know why my boolean component properties don't have an option to be linked to the boolean variables (don't have a diamond icon shown in video)?
I don't know why everyone is amazed by that, but that's not what designers really needed. we don't want to work with developers' approach and logic of how to make buttons clickable and spend time on specific preparations of components and mockups for expressions. as a designer, I never wanted to make development work! now you try to complicate our lives because we need to spend time not on experiments but on "make it work"
Nice. Very comprehensive. thank you. But, for people like me who hardly speak and understand english more than difficult. Especially because it digresses in many places. See Number 4 to Number 3 + expressions .... I have to watch this 10 times, or even more 🙈
After the next update, you will need to write code. and in one more update, the figma interface will be replaced with an IDE. It's good that the possibilities have expanded, but is it successfully implemented - the big question? There are a lot of bugs in the current prototyping, but in Figma they decided to complicate the life of users even more... Well, let's look.
Is there a way to create breakpoints that respond to the screen size using variables? Like when the max. or min. width of a breakpoint is reached the prototype changes to a different breakpoint.
Feels quite complicated, it would be great to see how other fellow designers use this and provide feedback on how to simplify this new function. Definitely a good thing to have but wish it was more straight forward.
I also feel the same. The thing that bugs me the most is that you are required to do all of this in a tiny floating panel, instead of doing this inside the whole sidebar on the right, which has more than enough space to work in.
You still have to do weird stuff like use "On mouse up" instead of multiple interactions "On click" when you want a button to-for example-update state and update a variable elsewhere on the page... this limitation hasn't been updated yet has it...
for simple things like Show/Hide, i feel UXPin offers much easier functionality. It would be great to see that function refined here in figma. Now, if we can get some actual Inputs where users can enter text...
A great innovation to further help the designers. But I feel failed to execute it right. Steps are way to complicated. Not upto Figma's standards. They themselves messed up the UX here.
It’s interesting to learn (as someone who is about to study HCI) but I honestly feel like i would spend less time using the usual variants than doing all these. But well once i get a hang of it 🤞🏾hopefully wouldn’t be a problem
yeah, some prototypes don't need to be that much specific. Much quicker most of the time to just iterate something that you can add comments to specify behavior and allow developers to also infer stuff correctly.
Back in the 90's we were building advanced prototypes in Macromedia Director Lingo. Since then prototyping in design tools has taken many steps back to a dumbed down interactive slideshow. That or going full in and building protos in HTML5. Product designers need this functionality.
@@Sinclair We need / want the ability to create advanced prototypes, and this is one solution for that. Still think it could have been implemented in a more intuitive way.
Being in software engineering, I find this impressive and not complicated. However, I can see how it confuses non engineer background designers from reading comments here.
I’d say, Don’t fret the confusion folks. Honestly, this is a huge, positive feature to the platform. It’s going to make the designers life easier and the developers life easier in the long run. If you take a step back and think of it from the users perspective on how the UI should change based off the interaction, you’ll then be able to easily apply that to the prototype without being confused by all these words like “variables” , “booleans”, etc.
Just think of the user interaction and trust your design abilities and this is going to be a massive productivity and highly interactive boost to your design workflows.
It is fascinating to see how Figma encourages designers to get more involve in adding logic to their design components. Not only does this make handoff to developers a breeze but motivates designers to think and really understand their designs, and how it needs to function for the platform their designing for.
I agree, this is exactly what the design world needed and what Figma delivered
As an Axure user for 8 years, I have been really waiting for variables in Figma. Well done!
Hey! I use Axure 8 yet too, as it's a lifetime license! And it works well until now! And the conditionals are much easier than Figma, as I watched this video. And it has way more options to do than Figma. But it's good to have those functionallities in Figma too!
@@fnonaka I continue to use Axure 8 as well, but I have less and less peers. 😆
@@parcival lol why less peers?
@@fnonaka There is a steady stream of new Figma users, but the Axure users are dying out in my bubble.
@@parcival sorry, what does it mean "dying out in my bubble"? My english is not so good!
Wooo!! I think this might be the first step where Figma evolves into a no code app development platform 🎉🎉
Yes it is true .Today figma launched dev mode😊😊
Paired with Anima it already is, but you always need to clean up and refactor the code. GPT might help for that. Also to connect it to your db/backend
I don't think this is the direction they intended with these features. But who knows, maybe one day Figma will turn into Flash.
It would need to be connected with external API and web services, backends etc
I really love how far prototyping is going, but it also scares me because it got so complicated.
It's basically stepping into programming (visually) so it comes with territory.
This is amazing. And is also a great effort to get designers close to JavaScript concepts and probably have better communication with developers.
programming concepts
Considering this (and way, way more) has been possible in Axure for years and Figma has basically copied variables and conditionals directly from Axure, while this is great, I don't think it's "amazing". It's definitely a step in the right direction.
@@tofuComputer Considering Axure is an absolute pain to use while Figma is extremely accessible by new and seasoned designers, I'd say It's still amazing. You used to have to choose: Axure for prototyping or Figma for hi-fidelity easy designs. Now all you have to do is use Figma unless you need extremely high-level prototyping needs.
My thoughts exactly
Love these advanced prototyping functionalities!
Small nit - in case anyone's wondering - in this tutorial, I find the variable names for the basket/cart very confusing.
Let's say on the World Peas website, we can add watermelons to our *Basket* by clicking on the "Add to basket" button. (Let's not call anything a "Cart" anymore - not in the UX copy, not in any of the variables/properties) Starting from 9:34, Our goal is to create an interaction like this: if you click on the "Add to basket" button, the appearance of the "Basket" button at the top updates to indicate that there is (at least) one *Item* in it.
Calling the local variable "Has cart" and the Basket button property "hasCart" doesn't make sense to me. (You can't say "The basket has a _Cart_ "; you can only say "The basket has an _Item_ in it".) If you're watching this video and you're like "What does 'Has Cart' mean??", replace it in your mind with "has item", and maybe it will make sense :)
The terminology used is not directly relevant to the feature being demonstrated, but it's distracting and is just wrong. Seems like a painfully obvious fit & finish oversight in the demo project.
Really love the new Variables feature, it feels like a big step on the journey to bringing design and code closer.
One small observation: binding visibility into a layer by right clicking on the visibility icon doesn't feel entirely intuitive. Right click always feels like a great go-to option but maybe not the first, most intuitive choice?
I was thinking the same thing when I saw that right click move
Exact same thought. I wonder why the variable icon wasn’t there like for other examples shown.
You can also make prototype mode semi responsive by creating a window variable and changing it's value on key press in prototype mode to change your designs width
This is great! I need to refresh my knowledge about writing if/else conditions. It's not just a design; it's going to be an app development. 🇹🇭🎉
Finally Axure found a prototyping competetior. Way to go Figma!
I love the narrator who ever they are + the background music. So chill I love it! 💜
OK we need a couple more things: 1. Component instance variables = values that live only inside an instance of a component, 2. onChange trigger on variables, and/or 3. toggling component variants based on logic on top of bound variable. Oh and 4., we need this on instances nested in other symbols, not just standalone instances.
Example use case: Want to create tabs. Need numeric instance variable activeTab storing index of active tab (alternatively string variable storing the label of active tab). Clicking individual tab in the tabs component changes the activeTab index to given number. (note all this is possible with "local variables", but would be needed on component level.). Final step: toggling individual tab variant based on activeTab value. Meaning if activeTab value changes from 2 to 3, tab no. 3 registers that activeTab == 3 and toggles its variant from default to active. At the same time, tab no. 2 needs to be observing changes to activeTab value, then finds out activeTab != 2 anymore, and toggles its variant from active to default.
I was right when I decided to choose UX design as my full time career after studying computer engineering! The line between design and development are going to be thinner and thinner going forward. It’s interesting on how prototyping has come along way. I remember how painful it was for me to iterate on my invision prototypes!
Looks a bit complicated but we'll see how it goes.
For those saying that it's dev work and a designer doesn't need this level of complexity: I quite disagree. Realistic prototype is required for a proper user testing plus it helps tremendously to demonstrate how something should work. Remember that not everyone works on simple things like websites. My current project is a very complex market research platform with lots of calculations and interactions. A realistic prototype of a feature within it will help 1) the client to understand how the feature exactly works 2) me to check if the whole experience is intuitive, reasonable, and just good enough.
That said, I agree with the comments that the way it's implemented doesn't look intuitive at first sight. For complex designs, it probably will be a bit of a headache
Is it me or this just seems overcomplicated in 99.99% of the design/prototype cases? You could just duplicate three or four screens and add all the interactions manually. You'll spent ten times less time doing this and the devs will catch the idea instantly. I mean if you make an interaction with 1 item available and 0 items available, with a full basket and a empty basket, any dev will understand the rules, styles and behaviour of the design/product. And I understand that this is a simple example, but even in complicated cases (I work daily on a huge app with thousands of screens and interactions) you can just divide the interactions or prototype and won't be a problem.
I understand that if you want to create a extremely functional prototype that is a 1:1 version of the product, well... this makes sense, but in my honest opinion the vast majority of users won't be working with this kind of mentality. It is great that we have the possibility of course, but at the same time they're bloating the UI with dozens of icons, dropdowns, etc that mostly everyone won't use.
I agree, it feels over-complicated.
They could simplify the solution, in my opinion, by incorporating conditions directly into components as well, instead of assigning them with only with actions.
For example, you can configure the component in such a way: if variable1 == true → change variant of this component into variant2
This approach would enable components to actively 'listen' for any changes in variables on a page, eliminating the need for creating lengthy, multi-level conditions.
Or maybe there should be a conditions panel in the right hand side bar, and there you could set up all conditions you want.
There are use cases for prototypes beyond communicating with dev
Agreed. Complete waste of time and waste of money for companies paying designers to do this where it’s basic knowledge for us developers.
The Adobefication has started
THIS IS AWESOME! I hope you include animation options for variable prototype interaction soon.
I remember that day, when I tried figma for the first time. I have no idea what date it was. But I was quite early. And her dress was so nice. It was love from the first sight. And it just keep growing.
This is so cool. With this we can reduce the frame we create and invest more time on the logic. Can't wait to test it out with the real product ❤
This is a stunning features for Figma and weak in terms of real programming. This difference makes Figma quite useless for business logic and UX designing (what the video actually illustrates), but may be useful for designing automation, simple prototyping, animation etc.
This is really cool - But I'm curious about how Figma handles the various screen variations during the handoff process for developers. Will they need to constantly run variables to see the different cases and screens? This is a new feature for Figma, but it's not for the industry. As an Axure user, I'm aware that Axure generates exported technical documentation that supports each variation, connections and interactions. Does Figma offer a similar feature? How will developers quantify their effort based on the screens? How will they become familiar with all the variations?
plugin development opportunity
Its good but will it work with design system. When you already have a button variants and now again create another set of variants to perform these conditions and variables. Its just complicated the things.
No way!!!! yeeeesss!!! finally!!!!! I've been waiting fo it for 10 years
i had cancer and died because of the narators voice. Good content tho
Wow this is absolutely a game changer!
How is the string variable (Cart Button Text) actually linked to the component variant? I don't understand how it could be linked to an unavailable button...
My team's component library includes prototyped components as part of our component file, which is published. Every design file which uses those components gets the built in interactions. How would I apply variant logic to different buttons within a design when the main component is located outside of the design file?
This is FREAK'N AWESOME... can be used to simplify so many things!
Thank you!
The fact that they correctly named it "Local Variables" for variables in the file gives me some hope that there are some plans for GLOBAL variables down in the road... :D
This is so amazing and really easy to understand and I'm over here overthinking every aspect of it
Not clear where that "Unavailable" trigger came from. If you set the conditional string to anything else than "Unavailable", it stops working. Why?
There's no way to apply a variable to a nested instance, right? I'm trying to create a "clear all" function for a dropdown menu, but the checkboxes I need to unmark are inside an instance.
And "reset component state" doesn't reset variables. Sad.
Amazing update Figma 🤩
This is an amazing, since The variable and boolean were initially made available by Figma. I was looking waiting for these upgrades in the prototype. Great update team. Awesome Job.
About time! This along with the new auto layout update will make it easier to make convincing prototypes.
Amazing, but the tutorial file is full of ready variables and prototyping. I think the file shouldn't be editable for anyone until duplicated to his drafts.
Feel like this feature is an overkill. The amount of time you spent on this could have been used to simply communicate with your developer using 2 more screens.
The feature assumes that the designer has strong logic and, in order to actually implement it, one needs to carefully consider where to apply it and how all the things are linked. With that being said, there are some advanced use cases for this for sure.
love this comment....its too complicated and it will not work with your design system, because you already have the button states and prototyping with variants now again you have to create another set of variants for this conditions. its not logically good.
Wait a minute. The string variable also changed the button component variant? How did that happen?
OMG! OMG! OMG! This is unbelievable. And the winner is... FIGMA !!!
En la nueva versión de Figma, ya no aparece en el panel derecho la opción de «Layer» en su lugar, aparece «Appareance»
quite complicated to learn. I wish you guys in figma continued easy and neat toolkit
This is still easy. Just need to learn a bit. Programming will be even quicker.
I gave up coding to become a pure designer but looks like I'm going back there. 🤨What we design is not even a real product, the developers are the ones who bring things to life. Not sure if I should be doing prototyping to this extent on a design. This is a good addition to designers who no nothing about coding though. Also this reminds me of Axure. :)
Thank you I been looking for a video like this ‼️‼️‼️‼️‼️👏🏾👏🏾👏🏾👏🏾👏🏾
Slowly making us learn to code, keep it up!
Just moved to a payed plan for this. It's all what I needed I didn't expected!
And that's also what they needed.
So powerful! Thank you Figma!
Looks good. But does it actually replace Axure? We make a lot of prototypes where users can fill in form fields, then use those inputs to personalise the rest of the journey. Looks like that one last feature is yet to come...
I wish they would just support standard web components like radio buttons, input fields, and select menus. That would make the prototyping process so much more intuitive.
Not sure if that feature will succeed, even though I follow the great tutorial the functionality seems too complex. When it comes to prototyping there are less screens but a lot more complexity in the few that remain (more cognitive load for users)
agreed
Hmm I'm curious how far the learning curve will change for UX bootcamps; Interesting the observe over the coning year.
Unfortunately this does not work with nested components at the moment. :(
Is Conditional logic coming to the Starter (Free) plan?
So much power in this tool!
Interesting update. Seems to go towards Axure while people switched to figma for it's simplicity. The entire variable concept seems unlikely to be used (maybe too soon to tell though) but replicating back-end conditions and logic simply doesn't seem to be needed.
If figma does wanna get into nitty gritty realistic prototyping, a simply user text entry capability while previewing might go a longer way. Until it's embedded inside handoffs, it's usage remains gimmicky.
There might be a use case of localisation/ language change at the press of a button which might be possible through this i guess, which might be useful
At 12:03, when you're updating the Cart Button Text variable to "Unavailable", you can also use the "Change to" option, to set it to be a different variant and achieve the same result (without setting up a whole new variable). Is there any benefit in doing it using a variable? This is definitely quicker. Using a variable is probably in line with how it is programmed, but that shouldn't matter while designing. Anyone?
I also thought the same - might be the presenter want to demonstrate how to use a string variable in a nested else statement.
I do the same thing about available variable, but when adding the instance card "unavailable" from the library, the instance itself turns into unavailable.
This looks fantastic. Although in reality how can anyone use this with the components one has on the design system?
If I ascribe all these values to one button then this button is going to behave and change all of this element at the same time. For example if I want to use the button component on as the subscribe button then the cart button and available items will update?
Is this method usable with design systems components?
Awesome. Just saved me from setting up a UX Pin paid account. What would be good is input widgets like input fields, selectors, etc and drag and drop components - - pleeeeeaasse?
watching this new magic like: rewind, replay, repeat 😂.. simple yet powerful .. okay, one more time! 🤩
That's my first successfully done tutorial of Figma channel 😅
Little tricky. Will take time to grasp. But amazing feature, content and presentation. Thank you very much.
This is a perfect use case for LLMs to translate designer intention into Boolean scripting! This is awesome as is, but hurts my brain a little!
Designer are going to become developers😂😂😂😂
Do the components have to be local for this to work? How would it work in a component library that is used across multiple files?
When making the # of watermelons text disappear when it reaches 0, Is it better to create a second conditional on click like in the video or just move "set variable #is available to false" to under the else action in the first conditional (thus only having 1 conditional statement for the click interaction). It seems to work the same as the method used in the video.
I have a quick question:
I cannot apply variables to instance properties when the instance is inside another component, why is that?
We can create a boolean in a master component with the values 'yes/no,' 'true/false,' or 'on/off.' However, when using Booleans in variables, we must use 'true/false.' Hmm, not really consistent. I used to use 'on/off' because of the shorter words, but now I have to change if I want to use variables in the prototype.
sad to say we cannot practice variables and conditional in Starter plan on figma :( we need to buy a professional plan for this to practice this new updates
I understand the point of it.. But, it's too much (and complicated) for a few things that developers also can understand it without all this complicated stuff for designers... It seems like the steps are going to be "front-ending" the designers and there are also going to be companies that require that knowledge from you because they expect you to know it along with so many other things. And in the end you know everything but you are not specialized in anything. Maybe I'm going too far with this but this is what I'm perceiving. I design and try to communicate well with the developer. Nothing else. If it wasn't like that, I'd have made another career as a developer. There are already places where UX and UI go hand in hand when in essence they are different things. Should I also develop?
Who managed to solve the design challenge at the end? Any tips?
Struggling with that one too :(
1) Create a local *number* variable called "total", and set its initial value to 0
2) In your prototype logic, when the "Add to cart" button is clicked (and as long as Amount available is still > 0), increase the value of the "total" variable by 3.99 (total = total + 3.99)
3) Add a new text layer inside the "Basket" button, with static text content "// $". Let's call this the "prefix" text layer.
4) Add another text layer right next to the prefix text layer. Let's call this the "total" text layer.
5) Bind the "total" text layer to the "total" variable
Hope this helps!!
This is just mindblowing!
That's BIG! I've hoped for that for a long time!
Took me a few run throughs to get this. The logic stuff is all fine but understanding how variables are bound to instances took a few goes. Simple now but wasn't all that intuitive.
As of now, I'm doing only landing pages. but if i get to use this, dang, i'll be able to use what i learned from my college degree IT. This set variable is easier to understand since i already have this knowledge flowchart and if/else.
It's amazing, But behind the scenes Figma getting complex and complex.
Does anyone know why my boolean component properties don't have an option to be linked to the boolean variables (don't have a diamond icon shown in video)?
How do I change other values in the process of applying a variable? Only the first value is set😿😿😿😿
Thanks for sharing the information. Is that variable available in the free version?
The best update ever! I love it! 🤩😍
lo veo muy tecnico
Missing attaching variables into component instances down the component tree.
I love this latest feature. Is this feature available in student plan? I want to implement it.
Can you use smart animate on variable prototyping? Be great to animate in elements, like a cart counter over the basket button
I actually did this with the variables :)
@@djwooster what's your secret? 😀
I don't know why everyone is amazed by that, but that's not what designers really needed.
we don't want to work with developers' approach and logic of how to make buttons clickable and spend time on specific preparations of components and mockups for expressions.
as a designer, I never wanted to make development work! now you try to complicate our lives because we need to spend time not on experiments but on "make it work"
Nice. Very comprehensive. thank you. But, for people like me who hardly speak and understand english more than difficult. Especially because it digresses in many places. See Number 4 to Number 3 + expressions .... I have to watch this 10 times, or even more 🙈
After the next update, you will need to write code. and in one more update, the figma interface will be replaced with an IDE. It's good that the possibilities have expanded, but is it successfully implemented - the big question?
There are a lot of bugs in the current prototyping, but in Figma they decided to complicate the life of users even more... Well, let's look.
Yes, it is well implemented actually.
Visual programming, right? Reminded me of Scratch programming software.
Not the most intuitive interaction, but what's new Figma 😕
Is there a way to create breakpoints that respond to the screen size using variables? Like when the max. or min. width of a breakpoint is reached the prototype changes to a different breakpoint.
Feels quite complicated, it would be great to see how other fellow designers use this and provide feedback on how to simplify this new function. Definitely a good thing to have but wish it was more straight forward.
I also feel the same. The thing that bugs me the most is that you are required to do all of this in a tiny floating panel, instead of doing this inside the whole sidebar on the right, which has more than enough space to work in.
Is there any way to detect the width of the outer frame and assign it to a variable?
Anybody else anxious that you now have to worry about other designers messing up your conditional logic and breaking your prototype?
You still have to do weird stuff like use "On mouse up" instead of multiple interactions "On click" when you want a button to-for example-update state and update a variable elsewhere on the page... this limitation hasn't been updated yet has it...
I just waiting for the video
for simple things like Show/Hide, i feel UXPin offers much easier functionality. It would be great to see that function refined here in figma. Now, if we can get some actual Inputs where users can enter text...
Welll.. why is there no "watcher" interaction? Its kind annoying to be only able to set conditional stuff on click.
This looks like it wouldn't work with a component library that already has variants that are used for general builds.
whaou great video and very cool functionalities! whit this calm explanations its very interesting ;)
A great innovation to further help the designers.
But I feel failed to execute it right. Steps are way to complicated. Not upto Figma's standards. They themselves messed up the UX here.
It’s interesting to learn (as someone who is about to study HCI) but I honestly feel like i would spend less time using the usual variants than doing all these. But well once i get a hang of it 🤞🏾hopefully wouldn’t be a problem
yeah, some prototypes don't need to be that much specific. Much quicker most of the time to just iterate something that you can add comments to specify behavior and allow developers to also infer stuff correctly.
This is super complex for most users...
Back in the 90's we were building advanced prototypes in Macromedia Director Lingo. Since then prototyping in design tools has taken many steps back to a dumbed down interactive slideshow. That or going full in and building protos in HTML5. Product designers need this functionality.
@@Sinclair We need / want the ability to create advanced prototypes, and this is one solution for that. Still think it could have been implemented in a more intuitive way.
is variable for paid version?