3 ms·

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 t

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.

zmgsabst 4y ago
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.
- viraptor 4y ago
  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.
Silhouette 4y ago
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.
- yjftsjthsd-h 4y ago
  Surely feature flags are a way to iterate privately even while shipping the code?
  - Silhouette 4y ago
    That depends on who gets to decide when the flags get turned on, doesn't it?
- brianmcc 4y ago
  +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-Removal/td-p/4800301 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.
  - Silhouette 4y ago
    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.

zmgsabst 4y ago

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.

viraptor 4y ago
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.

Silhouette 4y ago

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.

yjftsjthsd-h 4y ago
Surely feature flags are a way to iterate privately even while shipping the code?
- Silhouette 4y ago
  That depends on who gets to decide when the flags get turned on, doesn't it?
brianmcc 4y ago
+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-Removal/td-p/4800301 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.
- Silhouette 4y ago
  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.