Conditionals and variables are why I am sticking with Axure and not moving to Figma. It needs these before its ready for more serious prototyping. My team has become accustomed to the fully interactive prototypes from Axure; Figma would be a step backwards in terms of prototyping fidelity. Really looking forward to this feature!
Conditions and variables would help a lot doing a quiz prototype. Or at least let an interactive component changing the state of other interactive, with options to change to a specific state or to just go to the “next” or “prev” state to add value. Like a score counter.
I support this - other tools are doing it and it makes Figma seem too simple by comparison. e.g. items appearing when a user scrolls, certain fields or checkboxes being required to continue. It would ideally come with input fields that users can fill out, and that input datapoint should be referenced elsewhere. For example, when a user adds their name and email, that we can reference that name and email in the dashboard.
I agree, conditional logic is really important to have. No one wants to, or has time to create screens for every possible scenario when a simple bit of logic can serve up the correct state. PLEASE, Please, please add this to Figma.
Yes! Please, please add this. I’m prototyping a Next Best Action model and there’s so much conditional logic at play that my current project’s becoming super unwieldy to manage.
Hi! I am interesting in this issue. Any suggestion? I have not found any solution for this, anything except to create every scenario duplicating screens.
This is seriously needed. I’m torn between continuing to use Axure for a company project and moving everything to Figma. The design experience of Axure sucks; yet the prototyping is just so powerful in the face of what other software offers. Figma’s already grown so much, and if the team were to take this on this application would become a HUGE cut above the rest.
Same use case for me… triggering an error message when not all the form fields are complete - and making the submit / next button conditional on all required fields being filled out during user-testing. 🙂 So I echo that this would be a handy feature to make prototype flows more realistic
Basically, just rip this feature off UXPin (and make it work more smoothly). I remember I used to make protos in UXPin that were very very close to a finished product, however that software is (was?) so glitchy that I couldn’t bother anymore.
Conditions are crucial to some features to make sense at all, so it certainly would be nice to be able to test them too properly, before a single of code is written…
Piling on here to say radio buttons are a strong example of why conditions would be valuable. Since in a list of radio options only a single option can be selected at a time, conditions would allow the selected radio option to know that another option was selected and deselect itself.
A use case I’m currently dealing with: clicking a button on an alert should send the user to a different page depending on what object they clicked to trigger the alert. Currently the only way to do this would be to create an instance of the alert for each trigger, then wire the button on each alert to the corresponding page. Some basic if/then conditioning would eliminate the need for all these copies/manual effort.
Can you show us a short example as a series of image transitions (A->B->C etc.), or an animated GIF? It’s a bit hard for me to understand what you are referring to.
In prototyping mode it would be great to be able to trigger “change to” for elements by conditionally connecting them to other elements and interactions.
I want to show to examples here. I’m sure that are ways to manage it with the current figma functions, but it is from my pov very cumbersome. The examples are showing a very reduced UI - but I hope the idea can be transported.
It would be great, if I could tell the listitem in the menu to which UI the content should be swapped once clicked.
With this reduced UI, I see that there is a possibility to create the behavior by connecting frames. But imagine that the properties are laying in a bigger window, more properties below that should NOT swap.
My second example is UI that is dependend from each other. In the image you see a treeview, each listitem have a hover/selected state.
In the scene, the meshes also have a selected/hover state. If Mesh 1 is selected in the treeview, it should get selected in the scene. And if Mesh 1 is selected in the scene it should get selected in the treeview.
My current way to deal with this is that while presenting I say, where I’m focusing on. So first I go through the states when UI gets triggerd in the treeview. On the second flow I focus on the scene interaction.
But for user testing this approach is of course not very helpful because it does not reflect the final behavior.
One additional use case:
Depending on the content of a window, the buttons in the footer changes.
E.g. while in empty state the button is disabled. When content is inside, the button gets enabled.
Or if the button is bound to selection. E.g., you need to select an item in the window to enable the disabled button.
I run into a problem prototyping a situation. To give a context to the problem is as follows scenario:
I write my first name in an input field. I write my first name and then go to the second field to write my last name. I click and I see the caret blinking in the field. I change my mind and then click on the password, leaving my last name empty.
What I want to achieve here is that the placeholder display error when empty in the last name inputfield. (no mouse leave or mouse up or down int)
This would be useful for a calendar prototype.
When the user clicks a date, the date highlights (active state)and initiates an overlay keeping the calendar in view, when the user clicks another date, the date buttons act as radios, and the details in the overlay swaps view.
Radio buttons are the perfect use-case example
I’ve voted too. I really want to see this. It will save a lot of time building more sophisticated prototypes. Web apps for example would very much benefit from this.
Dearest Figma, we do really need conditions for form elements, if/else statement to ensure my prototype as close to real life as possible. When I am conducting UT sessions, allowing users to interact as they normally would needs a type of condition states.
The is so needed for switch elements, for form submissions and success/error states.
Please please it’s been over 12 months we all are requesting this feature…. It would be amazing if you can provide this feature.
If we don’t get this I fear framer software would surpass UX practitioner needs more than figma.
UXPin and Axure are products you need to learn from in terms of prototyping. Before you bring in proper tools this isn’t prototyping, it’s a slideshow for stakeholders.
With property controls it would be a breeze to implement basic conditional logic, UX wise at least. But before that we need a real input component like in Framer.
Would be great to have conditions !
I’m designing an onboarding screen with interest choice, would be great if when one interest have been selectionned then turn the button “Next” in active mode !
I’ll second others user case too !
Come on Abode ! Let’s to this 😉