3 ms·
You have to figure out what feedback is meaningful and what feedback is merely change aversion. If the users have a valid point, then maybe consider reverting.
by jakejake 15y ago
You have to figure out what feedback is meaningful and what feedback is merely change aversion. If the users have a valid point, then maybe consider reverting. If you believe it's just change aversion then you have to stick to your guns for the greater good.
Just like you said with Facebook, people will gripe about every change. But they gradually will appreciate the improvements as they get used to them.
- joshuahedlund 15y agoThis is a good point. Sometimes I definitely experience change aversion. But usually if I'm upset about a change it's because there was something that used to take one click that now takes three, or some kind of new complication or a feature that has been completely removed. It's even more frustrating to users if they make these kinds of points and you respond with "Change Aversion!" The trick is knowing the difference (or knowing when some complicated/removed features are worth overall UI improvements)
- jakejake 15y agoYea I know the feeling, I think if you remove a feature without providing any replacement then that can be tough on the users. Outright removal of features is something I try to avoid unless I felt like the software was moving in a directly that wasn't right. If something takes more clicks because it's a rarely used feature, that may be acceptable if the reason is to improve a more common feature that now requires less clicks. It's ultimately up to you to decide the direction you are going to take. If you really want a challenge, wait until you do an entirely new port or total concept change after people have been using your software for several years. They often get really cranky about that, even if the new software is miles better.