I completely agree. Is there a technical reason why this isn’t possible ?

Yeah, the way Figma does component variants the variant you are switching to on hover is considered a different item entirely, it is not just a modification of the original variant (the way it works in HTML/CSS for example). So when you click on a hovered item you are clicking on the hover variant, not the original one. This means the click action needs to go on the hover variant.

In general this is the way Figma does everything, styles and items aren’t actually changing, they are being swapped out or layered on top of each other. Smart animate can add a transition between these states, but the new state is still considered an entirely separate item/component.

I see.

Creating components then adding hover variants to them works well in the end. That was my solution to this issue 😁

Is there still no solution for this? Was wanting to have a dropdown menu item change color on click.

I actually think that the scenario above should be doable with current figma functions. You’d need to create a “hover” and a “pressed” state in the variant. You should than have the color change in your prototypes.

Thank you! Your clip helped me a lot.

Having this same problem. Feels like the “Overlay” option is being over-used to create tooltips (among many other things) but in the Figma world it’s still a modal-like component with an overlay mask which may be preventing/blocking the click action.

Figma is SVG/canvas after all.

More thought needs to go into the prototyping product (on Figma’s side) to better accommodate the html world of components, tooltips, drawers, tab panes, context menus etc.

Yet another example of figma designers not understanding how web elements work. All clickable items have a hover state. Implementing this at component level STILL blocks clicking action, not to mention not every button instance will have the exact same tooltip for example.

My dudes. There are a limited amount of basic web components. Just add a library of these. Add a library of stylable buttons THAT COME WITH customisable hover / focus / disabled states, unlimited additional hover objects you can associate with it (a button will highlight on hover, but can ALSO have a tooltip for eg), and then a click action. This mimics web behaviour.

Don’t even get me started on dropdowns. It’s ridiculous that I have to create a dropdown component with a million menu items that I then HIDE in case I need them in future. Just provide a library with a stylable dropdown component that you can say “I want 2 / 3 / 23 menu items with these labels, with or without icons”. Come on. This building component libraries from scratch business is mental.

Stop providing flexibility no one needs. Just give us basic components we can then customise.

This seems like a basic staple requirement for any interaction design to be able swap states on click, hover etc… and even to be able to add logic, e.g. if active state is applied don’t apply hover on mouse over, this would save me hours and massively reduce the complexity of my prototypes not to mention my sanity if anyone asks for amends!

+1 for this

+1, now let’s wait for the implementation

This is the way I did it. I created three frames, one where the button is, the second one the hover, and a third one with the new frame I want to reach after click. It works; after all, you want to click after the hover is applied.

I leave the public Figma file at the following link: Button Hover + Click | Figma Community

I have managed this fairly well I think but it takes a TON of work. And is not ideal to maintain…Figma really should be addressing this. It creates bloat and chance for error and inconsistency. But…

Bottom line is that your components have to be robust. Build them as COMPOSITES. Thus your button and then specific to that modal, action, etc. Then frame it and make it a component. Do the same for each of your scenarios. Now you have to load the proper composite for the proper button. Simple in theory, difficult to manage and maintain. But works great!

I needed a checkbox with hover tooltip. But then I needed the checkbox to launch a modal to confirm the action of checking it. What I did was made a composite of the tooltip AND the checkbox. Then “on mouse enter” of the checkbox, I showed the overlay and manually positioned the overlay checkbox over the initial one. Here I gave the click action to the checkbox contained in my overlay composite. Give the overlay a mouse leave to close the overlay.

Composites. Serving as workarounds for Figma inadequacy for years.

These are the simple things that Axure offers that I wish Figma was doing.

To clarify, if the hover behavior is added inside a component (changing its variant) then you can use the click in the artboard which contains it.

This is it! THIS is the answer! Thanks!

Just make its own feature work. It literally allows two different interactions to be added to objects, but only one works. Figma is going to put me into an insane asylum with all its non-working features like this

Its a shame it has to be this complex and figma can’t simply allow two interactions at once, but yes this works!

Additional tip: Don’t reset the bounding on your hover over instance so you can continue to use the same X, Y placement parameters.

Creating a button with a hover-effect from point A to B is simple enough. The annoyance of this today is that it adds “bloat” to your design files.

However, the main issue I face is when you are creating overlay components. I will try to break it down below.

Use-case:

1. Button within a frame opens a component


2. I want to add a hover-state to indicate a change and give the user strenghtened visual cues to the button


3. Clicking on the added hover-button opens up the overlay component


4. 
   Issue 1: When closing the overlay component the hover-button still acts as active. When building complex systems where a button exists across multiple screens this causes a lot of issues. For instance, on the overlay component you must today set the exist of the overlay component to an existing screen to “reload” all interactions. When the user is standing on one page he/she might therefore be redirected to a previous screen. All progress is thus lost. Issue 2 If you only add “close overlay” to an overlay the screen will freeze and the hover-layer will act as the main component. The only workaround is to restart the prototype.

I could keep going with all issues this creates…

Instead, I will add a solution. On each component there should be a possibility to add a hover effect. “Add hover effects” where you can add effects, backgrounds, font colour changes, etc.

This solution should not create these problems, since the button itself would work as usual, with the addition of simple colour/effect changes on hover.

Yes, same over here please 🙋

I think Figma fixed this in a recent update, I have button components with hover variant interactions that are working with click interactions now (not using the mouse up workaround)

Interesting, doesn’t seem to work for me.

My work around is to also include another invisible button with the tooltip.

1. 
   

   Real button with hover event to show tooltip
   
   

   
   


2. 
   

   Tooltip overlay w/ invisible button. Invisible button will have the click event to go to the next frame.
   
   

   
   

Mouse enter - Open overlay - (set your hotspot/tooltip overlay)

On click → Navigate to, etc.- (your next frame/screen/location)

Those two interactions work together on the same object or component if you follow these steps when presenting prototype (or mention when sharing) :

1.) Hover over area/button to trigger your hotspot/tooltip. 2) Over the same area that triggers it on, click to close it. 3) Without moving your cursor click again to trigger On click interaction.

Not perfect, but presentable.

Note: It won’t work if your h/t overlays the trigger area and your cursor is on top of the h/t… but that’s just bad design to begin with lol

While evaluating Figma I ran into this issue. I first thought this was a bug but according to the support it is by design. To me this seems like really weird design choice NOT to allow click and hover on the same element. I cannot think of more basic example of what should be possible with the interactions – quite usually UI:s have buttons which do stuff when hovered and clicked.

Please make both click & hover interactions possible on the same object @Figma_Support