[nkrisc]

I can tell you from personal experience on a UX team why it happens:

The UI is designed for features A, B, and C. We design, test, revise design, test, and so on. There’s more thought and rigor that goes into than you might be thinking.

Hurray, product launches, it looks good, and most importantly it works and users are successfully completing their tasks.

Now what? Well at the company town hall meeting the CEO announces features D, E, and F. Oh, there was a team already working on these features in isolation and the workflow is set in stone because they already built the back-end services and APIs. Ok, now we need to design UI for these features and cram them alongside A, B, and C.

If we were smart we designed the UI in such a way that it can accommodate new stuff, because we always know there’s new stuff coming down the line. It fits, but now the UI is getting a bit bloated.

Now here comes new features G, H, and I. Oh, by the way feature H is similar to E, but it works totally differently. They kind of fill the same role, so we need to make sure users aren’t confused by it. No, we can’t merge them because E is owned by product but H is the CMO’s initiative.

Cram more stuff in. Now it’s starting to get confusing, and the design that made sense for A, B, C, D, E, and F doesn’t really work with I because feature I does something that current user’s don’t really need, it’s meant to grow our market share.

Rinse and repeat until the only thing left to do is nuke it all from orbit and repeat the cycle.

In my experience it’s a symptom of a dysfunctional product culture, not overzealous UX designers. We’d rather not design new UIs for the same product constantly and do “refreshes”, we’d rather be fixing all the unglamorous problems in existing UI that frustrates users or get to the backlog of WCAG violations that no one seems to care about.

[cpeterso]

And existing users, who adopted your product because it already satisfied their need, may perceive any new features as unwelcome UI changes if they interfere with their existing workflow. As as told by https://x.com/scriffey/status/1493389985579417603:

I was next to my girlfriend when Chrome updated on her computer. It popped up a page of new features and she goes "I don't need this, I will never use a feature" as she closes it.

[nkrisc]

Every two weeks a member of the UX research team would present a report of compiled feedback and, oh boy, did we ever hear about all things people hated about any UI changes.

Their complaints are typically completely valid, but there’s only so much we can do. We can’t just leave things alone because there’s always some new feature or ad product to work in. We UX designers did not choose what to work on any more than the developers chose what features to build.

[wruza]

People have different layouts in toolboxes, sheds, garages, kitchens, bathrooms, etc. Whatever fits them best. They highlight main features and hide the rest in shelves. But when it comes to UX, everything must have its very fixed special pedestal for some reason. Not your fault, the whole UX thing is absurd from inventory management pov. We used customizable toolbars all the time before someone decided that we are too dumb for that. We still make bookmarks, pin apps to start menus, arrange apps on dashboards. Users aren’t dumb, the premise is.

[MichaelZuo]

For new features, submenus.

It might not always be the right choice because it could add enough complexity to discourage marginal users, but that’s different from not having something ‘we can do’.

[nkrisc]

Really just depends on the product and feature and the company culture. Submenus don't work when the feature has a powerful internal sponsor and they want it front and center.

[MichaelZuo]

Then you can still put the features that have weaker ‘internal sponsors’ there.

[nkrisc]

And then people complain on HN about “UX designers” hiding their most used tools in submenus, and the cycle is complete.

[whack]

To use coding terminology, there's a major distinction between "refactoring" vs "rewriting". Refactoring involves many incremental and iterative changes to an existing system. Whereas rewriting is discarding all incremental changes, and instead building a new system from scratch.

Refactoring is generally the most reliable way to improve a system. But rewriting is the best way to get promoted, and do work that feels personally "fun" and "impactful". I suspect this is the decisive factor in a large fraction of UI overhauls

[jcgrillo]

If people thought of pointy-clicky UIs in similar terms to the way they build CLIs there would be more refactoring and less rewriting. "Breaking the UX" in a CLI tool means that untold numbers of its dependents are broken. It's a breaking change to your public API, and it shouldn't be done. The only reason you'd do it is if your first attempt was a complete failure. We should treat user interaction with the same level of respect we treat all the other APIs.

[ffsm8]

> The UI is designed for features A, B, and C. We design, test, revise design, test, and so on. There’s more thought and rigor that goes into than you might be thinking.

What you're saying is spot on wrt new features in large corporations. That's not what is usually considered to be a "redesign".

Another thing about this is that these designers aren't actually users of the software they're designing. A recent example I stumbled upon the other day is portainer. It was a fantastic web UI back when docker got started, clearly made by people that had an issue and wanted to solve it. It had issues and warts, but it added value overall.

Nowadays it's not really worth using anymore, because none of the developers or designers actually have ever used it to manage anything themselves. It just doesn't actually solve any issues anymore, despite having lots of pointless features and looking more shiny now.

[jcgrillo]

Yes, I agree. When I've seen this happen the designers are never to blame, instead it's due to a lack of coherent product vision.