4 ms·

It's a self-serving simplification to make that criticism. There are lots of ways for a team to assess if users want to switch back to an old look beyond simply

It's a self-serving simplification to make that criticism. There are lots of ways for a team to assess if users want to switch back to an old look beyond simply counting how many find that setting. In-house usability testing, user panels, customer feedback, etc. And they're all more objective than a forum thread. Any product with millions of heavy users is going to have a subset that are upset by any change, no matter how positive it is. And if you make no changes, people complain that the product isn't being updated. It's easy to be snarky and whiny. Sometimes it's hard to remember that not everyone may see the world the way you do.

MaysonL 15y ago
What is interesting also is the total unanimity of user responses on the thread. You would think that some of the multitude of users who "love the new look" might have managed to find the thread and comment on it.
- jclulow 15y ago
  In my personal experience the probability of a satisfied customer seeking out a forum thread like this to provide positive feedback is vanishingly small. When things are working to your satisfaction, you mostly just carry on without thinking about them -- I actually quite like many aspects of the new look, and it hadn't occurred to me to do other than continue using it.
Lazare 15y ago
Oh, no doubt; the plural of anecdote is not "data", and that's all a forum thread of complaints is. And yet...while Google can fairly easily find out how people really view their changes, this does require them to want to assess that. And it's always been a little unclear why their app rewrite required a new UI. You'd think it might be easier to do that in two seperate passes... A suspicious person might suspect that the app rewrite and the UI revamp were purposefully tied together in order to ward off poor customer feedback. But as you say, it's easy to be snarky and whiny. :)
- tomkarlo 15y ago
  Given how much of the app is tied into the UI, a full rewrite would seem to be exactly when you'd want to make any major UI changes. I've been in that spot a few times myself and the last thing you want to do is re-create the old UX on a new codebase before implementing the UX you'd "like to have". In a perfect world you might even want to do the UX change first then rewrite the back end, but in reality if you did that you'd probably worry about losing support for the rewrite of the underlying plumbing once the new look has been deployed, since management often thinks of front-end refreshes as "delivery" of a new system.

MaysonL 15y ago

What is interesting also is the total unanimity of user responses on the thread. You would think that some of the multitude of users who "love the new look" might have managed to find the thread and comment on it.

jclulow 15y ago
In my personal experience the probability of a satisfied customer seeking out a forum thread like this to provide positive feedback is vanishingly small. When things are working to your satisfaction, you mostly just carry on without thinking about them -- I actually quite like many aspects of the new look, and it hadn't occurred to me to do other than continue using it.

Lazare 15y ago

Oh, no doubt; the plural of anecdote is not "data", and that's all a forum thread of complaints is. And yet...while Google can fairly easily find out how people really view their changes, this does require them to want to assess that. And it's always been a little unclear why their app rewrite required a new UI. You'd think it might be easier to do that in two seperate passes... A suspicious person might suspect that the app rewrite and the UI revamp were purposefully tied together in order to ward off poor customer feedback. But as you say, it's easy to be snarky and whiny. :)

tomkarlo 15y ago
Given how much of the app is tied into the UI, a full rewrite would seem to be exactly when you'd want to make any major UI changes. I've been in that spot a few times myself and the last thing you want to do is re-create the old UX on a new codebase before implementing the UX you'd "like to have". In a perfect world you might even want to do the UX change first then rewrite the back end, but in reality if you did that you'd probably worry about losing support for the rewrite of the underlying plumbing once the new look has been deployed, since management often thinks of front-end refreshes as "delivery" of a new system.