Can a UI change be a breaking change even when nothing technical breaks?
We usually think of breaking changes as API updates, database migrations, or features that stop working after a release.
But I've been thinking about a different kind of breaking change.
Imagine a SaaS product where users perform the same workflow every day. You redesign the interface, move a few buttons, rename some settings, and simplify the navigation.
Technically, everything still works. No data is lost, and no functionality has been removed.
But suddenly, experienced users take longer to complete tasks they previously handled without thinking.
From a developer's perspective, the release is successful. From the user's perspective, the product has become harder to use.
I think we sometimes underestimate how much people depend on familiar workflows, even when the interface could objectively be improved.
For makers who have redesigned an existing product, how did you balance improving the experience for new users without disrupting existing ones? Did you introduce changes gradually or switch everyone to the new interface?
Replies
Yes, and I did the extreme version of it: my current app replaced an older app of mine on the same store listing, so existing users got an update that was a different app with a different name. Nothing technical broke for them, and that is exactly your point, it still is a break. Two things I hold on to. Keep the identity people navigate by, the listing and the place the icon sits on their phone, and change the inside, not the address. And log taps under fixed control names, not labels. When someone writes in after a change, their log shows the path they took, and a renamed setting keeps its logged name, so you can see where they went looking for the thing that moved. Gradual or all at once matters less to me than being able to see that hesitation.