6 ms·
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
by wiremine 4y ago
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-background-colour-from-yellow-to-white-ffd9718e7bb https://kulor.medium.com/how-ebay-secretly-changed-their-bac...
- alexb_ 4y agoEasy 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.
- lazide 4y agoSometimes even a color change IS a major function change too, especially if you have business customers
- daniel-cussen 4y agoYeah 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.
- tremon 4y agoYes, 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.
- philihp 4y agoFeature/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 agoIntuition 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 agoIt'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 agoI 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.
- _8j50 4y agoNo 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.