Hacker News Reader

Comment by wiremine | Hacker News Reader

Small, "rapid releases" don't need to all go to the end user at once. That's an anti-pattern for solid UX design.

The classic "eBay color change" comes to mind:

https://kulor.medium.com/how-ebay-secretly-changed-their-bac...

Yes, they do? I thought the entire idea behind "release early, release often" was to shorten the feedback cycle between code changes and user reports so that it's easier to fix the issues?

However, not every code release needs to include a UX change. I agree that changing the UX every week is a solid anti-pattern.

Feature/UX changes should be behind feature flags, and launched independently of a release. Releasing often let's us identify and fix bugs quickly. I hear you that as users we appreciate more stable UI, but to get to an intuitive UI, you have to experiment and iterate.

While there is value in discrete and planned releases, we value responding to change more.

I hear you that as users we appreciate more stable UI, but to get to an intuitive UI, you have to experiment and iterate.

But there is no rule that says you have to do those experiments in production and annoy your paying customers who don't want to see them. If you didn't insist on releasing every five minutes you'd have time to iterate privately. Successful software was made this way for decades before modern web applications came along and frankly a lot of it had better UI/UX than a lot of the junk that gets pushed out today.

While there is value in discrete and planned releases, we value responding to change more.

I suppose the question is what change you're responding to. In this situation it seems like a lot of that change and the need to respond to it are self-inflicted damage.

+1 for "let's run this big UI change using our TEST platform past some physical rooms full of typical users to see if they hate it" rather than just firing it into prod with some buzzwords to justify traumatising millions of previously satisfied customers!

Personal favourite was Spotify removing their playback widget to "improve the customer experience" and oh my God the backlash was ferocious. It was entirely moronic and screamed of Product Manager -> Customer with zero actual user feedback gathering:

https://community.spotify.com/t5/Android/Android-Widget-Remo...

26 pages of complaints produced this response, basically we removed a thing you love and use constantly, but you can vote for it as a feature request:

"We always take retiring features in Spotify very seriously, and do want your continued feedback. The best way for us to measure your comments are via votes in our Idea Exchange.

For this reason we're going to lock this thread. We encourage you to move to the Idea Exchange area where you can vote and comment on feature requests."

Approaches and terms like "iterating fast", "responding to change", I dunno, just feels like a poor substitute for better planning and evaluation because those can be hard.

The irony is that it often takes only a tiny number of test users to spot a glaring usability problem that could sink a major UI change. Someone (possibly the Nielsen Norman Group?) did some research on this a while ago and found that even single digits of test users would be enough to collect very useful feedback.

People are so obsessed with scale and techniques like A/B testing today that they seem to forget that kind of test can only tell you whether one of the options is significantly better. It can't tell you whether you're finding the best choice between excellent options or the least of evils between dreadful ones.

Totally. You could imagine even a tiny handful of trusted users who consistently give valuable, reliable, feedback.

Microsoft seems a company just oblivious to user feedback - Beta users howling about disastrous Windows changes mooted, and they just.... ignore them. I don't get it.

> frankly a lot of it had better UI/UX than a lot of the junk that gets pushed out today.

I feel like this is the key point that adherents of modern development practices need to address. We've been sold a lot of stuff on the basis that it would drastically improve the user experience - but a lot of people, myself included, feel that UX actually declined in the past two decades.

I think software quality has fallen in many areas - including UI/UX - as a result of widespread Internet access. It's no longer assumed that anything actually has to work when you ship it because you can always fix it with a software update later. There's no need to do real usability research before you ship because you can always spy on users later.

Unfortunately this seems to have created a culture where little that ships was really ready - at least not to the standards we used to consider acceptable. Everyone is busy pushing out new features and other visible changes every ten seconds. But somehow no-one ever finds the time to go back and fix the substandard quality that got an MVP in front of users on launch day.

Google even warned us about this years ago. Remember in its early days everything was Google XYZ Beta? It was an excuse to ship stuff with substandard quality then and it still is now. We're just less honest about it now.

Surely feature flags are a way to iterate privately even while shipping the code?

That depends on who gets to decide when the flags get turned on, doesn't it?

Intuition is learned patterns.

You can’t have an intuitive UI if it’s constantly changing so designers look productive in sprints: you’re constantly defying the intuition for your current product, while giving users no stable target to learn the behavior of.

It's about learned patterns, but not learned patterns of a specific version of your app. For example at this point intuition is expecting the hamburger icon to open a menu. It's not about expecting the green circle to open the menu because it's done that in the previous version of your app.

You can definitely have both intuitive and changing UI if you think about it.

That was when users were other programmers or at least techsavvy. Not my 76 year old mom.

Easy when it's a color change, but this attitude is horrible when it comes to anything functional. You stop being able to learn how things work because someone wanted to make a small tweak, and now you don't even get notice it's happening.

Sometimes even a color change IS a major function change too, especially if you have business customers

Yeah scrapers and in any case if it changes the black and white text to both being the same cool gray. No joke.

This forum gets hacked into that, you can't see points a comment gets unless you measure it by the gray of the comment, in which case you can tell exactly when it has 0 points, or -1, or -2, or -3, or -4. Scrapable, and illegible. Opens itself to voting rings. Not even legible if highlighted, you need to copy-paste to another application.

I brought this up formally.

No such thing as small when you don't know what features of your product users rely on. You might affect 0.5% of users at any release but given that is different users each time you will piss of many of users. The thing is, no one seems to care since everyone is doing it.

Reply on news.ycombinator.com