* 'Excessive change is generally better than no changes at all.'
Can't agree with that. If the change isn't needed then change can't be better. The burden of responsibility for justifying the change is on the person wanting the change. To identify why the change is needed and how it's an improvement.
It's a weakness of the production team if there's a "must evolve no matter what" mentality on repeat-cycle. You could aim for "stability", for "baseline" for "solid foundations" instead of "excessive change". Then your efforts are about extending, expanding and tweaking rather than changing.
There's nothing subjective about evaluating reasons for changing an interface. There's either good reasons for the change, or there isn't. Too many people try to manipulate discussion in this business with "it's subjective". It dilutes the discussion because "subjective" doesn't commit either way, it just kind of shrugs and says "oh well, too hard to conclude anything".
When a consequence of change is that you piss off a bunch of users, then you can't say that change is inherently better each iteration. A wrong turn might be made and literally breaks the product or dents the reputation for many iterations. It happens. Nothing is immune from the great unwashed interface testers, and we don't like useless layout changes for things already committed to muscle memory.
> If the change isn't needed then change can't be better
I'm curious... when you say 'change' is there a contextual limit to what counts as a change? That is to say, am I taking you too literally if I consider an A/B test a change? Or is there a pervasiveness of rollout that you think is necessary to consider something as a change?
In either case, I wouldn't want to underestimate the value of studying reactions to a change--especially the negative reactions. There's a lot to be learned from mistakes.
Valid point, but clearly even the smallest changes upset people. Re-arranging furniture is a change. Changing the colour or number of cushions on the sofa is a change.
A-B testing won't reveal how many people reluctantly embrace the change, rolled their eyes and cursed your service as they completed the task. A-B testing is not all-knowing. It's suitable for colder functional changes, not things such as key separators on a virtual keyboard.
None of this would be a problem if users are simply given choice and meticulous control over the changes and how or whether they're applied. Choice, control, options and user preferences - those should be the key features. I wish for innovation in changes, such as inviting and allowing users to preview for themselves a particular change.
Fortunately we do have lots of options in our settings for a lot of things, but it doesn't go far enough. Their new "material girl in a material world" design philosophy is a distraction... and personally I think is weaker than commentators are declaring.
Who wants reliable, familiar interfaces and predictable functionality? Um.... try everyone!
I get that these changes are pain points for lots of people, and no one wants to be frustrated using the devices with which they have everyday, critical interactions.
> Who wants reliable, familiar interfaces and predictable functionality? Um.... try everyone!
Sure we want that... and we also want newer, better things. That's a tug of war between comfort and progress. If all we did were laser-focus on reliable, familiar interfaces and predictable functionality we never would have gotten the GUI or the mouse, right?
> A-B testing won't reveal how many people reluctantly embrace the change, rolled their eyes and cursed your service as they completed the task. A-B testing is not all-knowing. It's suitable for colder functional changes, not things such as key separators on a virtual keyboard.
I completely agree. My point was to home in on what you would characterize as change. Your response was very helpful to that end.
> None of this would be a problem if users are simply given choice and meticulous control over the changes and how or whether they're applied. Choice, control, options and user preferences - those should be the key features.
Yeah, it would be comforting if the gmail app let users toggle between "classic" and "material"... and it would also be contrary to that which is (seemingly) the driving force behind Material Design: defragmentation of UX in the Android space.
Choice is a double-edged sword. Several studies suggest that choice overload reduces happiness, increases stress, and leads to poorer decision-making.[1] On the other hand, one study found that choice overload caused all of those reactions but also positively affected their perceived quality of the brand.[2]
We HNers are a niche of tinkerers who enjoy poring through settings. As I understand it, our love of actively customizing and tweaking is not shared by the larger demographics.
Change bears risk, yes; but personally I would rather groan at questionable changes than ploddingly use an app that sacrifices the hope of exceptional change for the fear of bad change.
Can't agree with that. If the change isn't needed then change can't be better. The burden of responsibility for justifying the change is on the person wanting the change. To identify why the change is needed and how it's an improvement.
It's a weakness of the production team if there's a "must evolve no matter what" mentality on repeat-cycle. You could aim for "stability", for "baseline" for "solid foundations" instead of "excessive change". Then your efforts are about extending, expanding and tweaking rather than changing.
There's nothing subjective about evaluating reasons for changing an interface. There's either good reasons for the change, or there isn't. Too many people try to manipulate discussion in this business with "it's subjective". It dilutes the discussion because "subjective" doesn't commit either way, it just kind of shrugs and says "oh well, too hard to conclude anything".
When a consequence of change is that you piss off a bunch of users, then you can't say that change is inherently better each iteration. A wrong turn might be made and literally breaks the product or dents the reputation for many iterations. It happens. Nothing is immune from the great unwashed interface testers, and we don't like useless layout changes for things already committed to muscle memory.