Allow component instance overrides to be inherited by all states
Currently (XD 24.0.22.19), if I drop an instance of a component and then adjust part of it (text in a button, size of the instance, etc.), that override is only applied to the selected state of the instance. So, if I have a button with many states (normal, hover, disabled, active, default action, etc.) I have to manually apply that override to each state of the instance. This is extremely tedious and error prone.
Please provide the ability to have an override of an instance be inherited by all states in that component instance.

-
Jenni Merrifield commented
OMG. Yes, I need this! Please!
-
Anonymous commented
I am again surprised that this feature isn't there. There should be a way to select the whole button and resize all states, rather than just the default one.
-
Roel Berends commented
I could really use this feature.
-
Sebastian Hösl commented
I need this!
-
Jesse commented
The lack of this functionality is making me push my workplace to use Figma or Sketch instead of Adobe XD. Many wasted hours on changing the text on additional button states.... sigh
-
digita commented
Too much manual and time-consuming editing, please improve it.
-
Piotr Braszak commented
Yes, please, so very much! I got a project that spans across over 250+ artboards. All of them use some master components, and if a feedback comes to change a certain component, it'd save me unbelievably large amounts of time. Not to mention all buttons that come inside that component too.
-
Anonymous commented
I agree that I have spent hours reorganizing components because of this issue. I used to work with Sketch and Sketch identified a text field/color/icon as a part of a component that could be specific to a particular instance and provided a panel for modifying these for each instance. With XD, the component panel is only useful for hover and click states, but not for repeating styles. This is very disappointing!
-
uiux designer commented
would be highly appreciated
-
Anonymous commented
This issue makes the states feature very difficult to use. If the user creates a new state and edits one element of that state, it should be treated as an override. The new state should still inherit all other properties from the default state and any changes made to the default state should propagate to all other states unless there is an override present. This is the way it would work in simple css.
-
Anonymous commented
may i ask, how this is still marked as "feature-under-review" but in the forum someone said, u are actively working on this (since nov 2018) how is this not done by now? this renders the feature almost useless
-
Cervantes commented
This means I just simply can't have a functional and interactive design system. So now I have to delete all my components states because when I interact with them it is absolutely ugly. This should not be a feature but a bug fix. What it the point of having a library of components with different states if you can't interact with them? It prevents me to do a good job in my company. This issue has been highlighted for a long time now and you can't even give us a proper time frame to fix the issue.
-
Beyhka commented
I am also looking forward to seeing this update made. The states almost aren't usable otherwise.
-
Anonymous commented
I'm literally having to remake all of my components. I have a UI Standards Guide with master components. If I drop a master component from my standards guide(for example a button) into a new design(file), then create a table (for example) that includes this button component (with a new label), then paste the table back into my UI Standards Guide for reference, it reverts the button to the master component label and width. Is there any override for this? We also, need a way to create a master component from a modified component.
-
James commented
Yep, obvious really...
-
Joo Chung commented
We REALLY need this to be a thing. I waste so much time with asset instances having to get all of the text the same across instances. In our design system, like many others, we have various button states, and the fact I have to copy the custom button name into every state manually is just ridiculous. It really makes me wonder if the folks who program this software actually use it. These wasteful microinteractions add up, and make the experience time consuming and frustrating.
-
Brian commented
Brilliant work on this application so far. Thank you for the hard work.
Of course nothing is perfect ;-) - As a visual designer, it's really important that I can convey the animations and micro interactions to stakeholders where possible in my high fidelity visual mockups.
Unfortunately, the process required to do this relies on my re-use of button components with built-in states. These states don't inherit the new labels and icons when I override the instances. This means I'm editing the following for every button I override:
enabled, hover, focus, pressed, selected and disabled .... it takes a looooong time. -
Tony commented
Recently started using XD and I can't believe component states were added without thinking about this since the whole point of components is to be able to make a base design and use it throughout your design with slight changes.
If I change the text on the default state of a child component that change should be there on all states just like if I did it on the master I shouldn't have to retype it for each one. And the same should be for nested components; I'm currently working on creating some CTAs that all have the same look but different icons. I should be able to replace the nested icon component with another and it should replace it for all states and a bonus would be that it takes on any color changes I made for the other states.
-
Adam Trabold commented
yeah, this is a giant timesuck for us as well. we've completely stopped using hover states because of how frequently we'd forget to click into the hover to edit text on a button, for example. gets really confusing when those accidents make it out the door during a usability test or something.
in my opinion, text should follow the same rules as everything else on a component state...if you have states, the link between the default state should only be broken when it is specifically changed on a non-default state.
so...if i change text within the default state, it should populate all other states, unless i've manually changed it inside a child state.
-
John commented
Yeah soo annoying... Please fix this immediately. Also let us reset individual item states, e.g. like Sketch where you can reset the Text or Color override, etc. or even reset a sub-component override (when you use a component in another component).