I want to push back on this idea that designers are out to destroy everything. I think one interesting way to look at these sort of changes is analogous to the

I want to push back on this idea that designers are out to destroy everything. I think one interesting way to look at these sort of changes is analogous to the introduction of new features in code. In the short term, new features can be added to the existing codebase without the need for much change, but eventually, the overhead becomes problematic and there is the need to make more structural adjustments. I think it’s similar for designers, who get to the point where new features don’t have a natural home in the existing interface and want to make changes. Just as a junior developer might be tempted to rewrite from scratch, a junior designer might be tempted to introduce a new mental model and rearrange everything. In some cases this may be OK but generally you need a more nuanced approach. The fact that users are the consumers of the change, not designers, is where the analogy falls apart, and thus the need for a more thoughtful introduction of any change. Obviously the abrupt changes are those that cause a negative reaction, especially when combined with the exaggerated desire to clean up an interface. However, not all change is for changes sake. Sometimes it’s just a case of trying to respond to constraints and make the best compromise when dealing with changing software.