The classic "eBay color change" comes to mind:
https://kulor.medium.com/how-ebay-secretly-changed-their-bac...
However, not every code release needs to include a UX change. I agree that changing the UX every week is a solid anti-pattern.
While there is value in discrete and planned releases, we value responding to change more.
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.
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.
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.
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.
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.
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.
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.
You can definitely have both intuitive and changing UI if you think about it.
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.
There’s something terribly wrong in the picture you’ve described. I do not know what Agile stands for, but our company was doing “a new version each Friday” for like 15 years. One of the axioms of such a fast turnout was “a new version should work in the old environment exactly the same as the old version” - except bug fixes of cause, some of which were made optional nevertheless.
Small incremental change is easier to test in most cases, the issue is, changing software that was designed as a whole over to incremental feature improvements is hard, because often the existing bulk of code cannot be meaningfully unit tested.
Today it's just the wild west of people basically having production not far sepeeate from development in terms of changes. UI/UX changes are the worst in this context. I opened Venmo the other day and I had to waste 5 minutes because someone decided they wanted to change the UI and I had auto updates applied (shame on me I suppose).
Do not change the interfaces with your users folks unless it's truly broken.
You may have more patience and composure but most of everyone is sifting through countless activities in a day. 99% ill close the tab than wait for a 5 minute update for an activity im not getting paid to do.
But that doesn't keep programmers employed, VC's making money, or management justifying themselves.
Frustrating.
All I needed them to do was improve performance for large libraries.
The irritation is tripled if it's an un-skippable "let us walk you through the nineteen changes in a slowly constructed slideshow!"
This is second only to applications that don't properly retain state--especially after an update--so every time I open them I get a brief glimpse of what once was (and what I probably wanted to go back to) before I get a 50/50 split of being dumped to the application home screen or "oops, something has gone wrong! lol, software, yannow! Please to be logging in once more, thx."
>click next.
>click next
>click next
[support . apple . com]
"Hello, my inquiry is whether or not AppleCare+ covers spontaneously throwing my laptop out the window thus it falls down three stories into a storm drain. No, this is purely hypothetical. Yes, I'll wait while you research."
I'm strict on this; I return video games with unskippable tutorials. It's cause for an immediate Alt-F4 and return to store.
Many features are better off hard to find and left that way than shoved-in-your-face discoverable, or introduced by a tutorial. Those who want to get the most out of their tools will find them and will appreciate you treating them like fellow intelligent beings. The rest will never know what they missed and won’t worry about it either.
Lots of game developers have conducted extensive research and found that player retention is considerably higher when you "annoy" them with these things rather than just throw them to the wolves and tell them to RTFM.
There's basically two reasons to make games: to make money, or to make art. You can try to do both at once, of course; and focusing on one doesn't necessarily detract from the other.
Consider FromSoftware, for instance; often pilloried by the gaming press for their lack of difficulty scaling or tutorials, but adored by their fans and able to turn a tidy profit with each release. Similar, but less well-known, would be Spiderweb Software; which has steamrolled along for decades without breaking their artistic style.
Not everyone wants to be the next Candy Crush or Clash of Clans; many just want to create an experience that they would enjoy.
From Software games are more hands-off because their goal is to make the player discover the mechanics and systems on their own. Not every game wants to do that, and as such I don't think games like Halo: Combat Evolved or The Legend of Zelda: Ocarina of Time are automatically worse for this. In the latter case, I think the unskippable tutorial section pulls double duty in setting up Link's backstory; You're with him as he first learns how to fight, use his shield, etc. before going off on a grand adventure.
From Soft games are also not immune to the unskippable tutorial mission. Both Elden Ring and Sekiro start you off in a relatively safe linear level with pop ups teaching you their basic mechanics.
I want to circle around back to the comment that started this though, because that user said they immediately uninstall and refund any game with an unskippable tutorial. Maybe they meant this as hyperbole and I'm just sitting here wooshed, but it seems like an extreme stance to take.
Indeed, tutorials do come in a great many varieties, and when it's done well the user may not even be aware that what they're experiencing is a tutorial. That has a strong tradition in game development; where a new ability or a new tool is provided to the user and the level is designed thereafter to allow the user to explore that new thing. That's closer to your Zelda or Halo.
Even FromSoftware games take this approach. Elden Ring has a whole opening stage that's clearly designed to expose users to core gameplay mechanics.
But then there's those unskippable dialogues, or the tedious "now press this input to perform this action" prompt found within a purpose-built tutorial area. Those, specifically those, are what I find cause for immediate product return.
There was some Need For Speed games on the PSP that were particularly awful for this. You'd be _racing_ and it would pause the gameplay to show you a dialog about how to drift or draft or somesuch; completely breaking the flow of the experience. That's what I would demand a refund for.
That said, art is subjective, and the experience is ultimately defined by the beholder. Maybe some people actually enjoy being brow beaten with unskippable prompts and hand-held through tediously constrained environments, with their experience jarringly interrupted at unexpected times by dialogs that break the suspension of disbelief.
The Northern Asylum in Dark Souls is one long unskippable tutorial.
The tutorial is basically the intro video with some tool tips periodically in game.
Which is why, for the most part, I've stopped using web-based applications.
Edit: not sure why this was downvoted. Did someone find the idea of a narrowly-focused phone to be offensive or unworthy of discussion?
We're not sure why you went to describe how you read emails, and that's why we downvote you. Your answer was completely irrelevant !
Interesting, I don't have a google account associated with my phone. It means the google app store doesn't work, but everything else works fine AFAIK. I use FDroid or just download apks directly.
Rapid release and experimentation means ultimately finding better solutions for the users faster. If you go slow, things don't change as much but they don't get better much either.
We tend to assume that all of the good changes would have happened anyways and all the bad changes are because of rapid release.... but that's not how it works.
Better UI is not universal. And the absolute, hands down unquestionably best, UI that can possibly exist for any given customer is the one they're already an expert in.
Can a different UI end up being better for them? Sure. Will it be better the day it's released? No.
The user has to pay a cost every time the UI changes, regardless of whether it's actually better for them or not (and it will never be better until much later, once they've become an expert in the new version).
Worse - I see more and more companies optimize UIs for the "initial user experience" and onboarding new users (more paying customers). The sad truth is that many times that means dumbing down a much better UI for the "already expert" customer - just like putting training wheels on the bike is great for the person that's never biked, and utterly infuriating if you already know how to ride.
This is why existing customer bases are so rarely fond of any change - regardless of whether they end up liking it in 3 months time. It has a real cost, right this second, and they're being asked to pay it.
If you already spent months training a new hire on how to get something working with all the different random tools and software they use, changing something meaningful means breaking that persons ability to do what they need to do for their job, at least for some time.
Even changing something inconsequential will confuse some users for a bit, require making/updating new training guides, etc.
If it’s a business on the edge or under during a stressful period? That can literally tip it over and make it non functional. That is especially true for small businesses.
This is one of the reasons business productivity software becomes unwieldy after a while -- it's fine to add buttons and menus, you just can't change existing ones or what they do. So then version 5 will finally introduce the massive, desperately needed UI refactor after ten years, while plenty of clients just stay on version 4. (An example of this is the Blackbird CMS -- old Blackbird vs new Blackbird.)
If your new product with ten years of improvements was so unattractive compared with the existing version your customers are currently using that they were choosing not to update, what does that say about the value to the customer of all those improvements?
In the world before SAAS we saw both extremes often. Some products had incredible dev teams and people would upgrade relatively often even when each new version cost extra money. Other products barely produced an interesting change in several new versions over several years and users mostly didn't pay for those updates.
SAAS is a convenient business model for the developers in the latter category because it locks in the ongoing revenues whether any future changes add value or not. They just need enough lock-in effects that once you've signed up you can't easily move to one of their competitors.
Then, switch to new vendor or the next major version.
Software Lifecycle for reals baby!
It's also built with table elements. The programmer in me is screaming because that's not the proper use of tables (I know that was the way to build layouts in the past, but that was then and this is now). The UXer in me is screaming because it's a nightmare for accessibility.
I want to add that I'm not coming from the "Overengineer-and-Bloat-Every-Website" UX School of Thought, so I agree with your point about Reddit. Being performant and light on resources is part of what makes a good UX, but that's the thing: there's more to UX that loading fast and running without hiccups. I think HN's experience could be greatly improved without compromising in any of those aspects.
The default font size is unreadably small, it's impossible to reliably tap on upvote without accidentally hitting downvote on mobile screens, comments with code blocks with too many characters in a line break the width of the interface, huge comment threads indented 15 times aren't collapsed by default, downvoted comments lighten to become unreadable, I could go on.
But there's no decent alternative for HN's content and community, so we put up with the terrible decade-old interface because we don't have a choice. Although people are constantly inventing their own clients for it precisely because it's so terrible.
The only of those complaints I even half recognise is the voting buttons on mobile, but I miss them rarely enough that I’d probably still rather not give up any more screen real estate (horizontally or vertically) or add an extra click.
Otherwise HN has basically the UX I wish every site had.
Frankly, neither programmers nor graphic designers are qualified to make good UI decisions. Human factors is a real field that people get PhDs in. You really can't just wing it, especially if you're a programmer whose mind has been thoroughly addled by decades of using programmer-designed UIs from the Nth circle of hell.
If HN had such great UX, there wouldn't be multiple browser extensions (and clones) that focus solely on fixing the UX. I'm not saying the UX is terrible, but I wouldn't call it great. I think the best term for it would be "consistent." It's basically Craigslist. It's fine if you've been using it for years and have adjusted your behavior to work with its quirks, but it does not provide a smooth experience that would work for a community you're starting today.
Just because there are other products with different experiences that skin it doesn’t mean the core product is bad!
It actually means the opposite - the core product has such value and there are so many users, it actually is able to support sizable enough communities of people ‘outside the core’ to justify niche repackagings for them!
Great UX should also mean fast, efficient, and dense with information. Respectful of time, attention, and intelligence. Not making an assumption of stupidity on behalf of your users.
Great UX should primarily mean those things, at least for a certain subset of software.
Making links in profiles and text posts clickable. That's like the most basic thing you can do for your users.
Adding the ability to collapse a massive comment thread without having to scroll to the top. Also, indent guides (especially needed for the massive threads around here). Shit, HN didn't even have collapsible comments for the longest time.
Being able to comment inline and not having to navigate to a separate page where you lose context of the surrounding discussion.
Highlighting new comments since you last viewed a thread.
These are all basic things that HES addresses, there are many more I can point out. I'm not trying to insult the admins, I think they do an amazing job of running the site, but let's not pretend HN is some pinnacle of UX design. We are all just very used to it.
And personally, in the years I’ve been here I’ve never noticed or cared about any of those issues. shrug
Adding a ton of features almost nobody uses and rearchitecting the site using 'modern' frameworks, only to make it 10x slower goes right againts that oath.
The funny thing is that HN doesn't even adhere to the basic UX practices that many around here constantly complain about in new design like knowing what is clickable.
Take a look at each story list item on the front page, what do you think is clickable? Everything in the subheading is formatted exactly the same, but not everything is clickable. Same goes for the headings of each comment in a thread. And I think HN's violation of this is especially egregious since the formatting of these things aren't just the same, but they are greyed out. That's a pretty universal sign that something is not clickable. This is 100% confusing to new users.
This one is a bit more difficult to implement without a lot of JS, but one thing that I have run into many times is reading through a comment thread, trying to reply, realizing I'm not logged in, logging in, losing context of where I was, scrolling through the thread trying to find where that comment was, giving up and not commenting.
In addition to that, not remembering which comment threads have been collapsed. Accidentally navigate away? Good look finding your place again, especially if there were many new comments added.
The mobile experience can be summed up as "very precise clicking"
I think the top menu items are also named in a weird manner. Why does comments take you to a list of random comments in chronological order? How is that useful? You would expect that link to take you to your profiles comments, but no, that's the "threads" link. There is a lot of that on HN where things are (imo, purposely) obscure. I get why they would do it, but let's not pretend it's a good experience.
HN caters to the most technically literate community on the internet. They will figure out how to use this site no matter if you had to navigate the site via the terminal (some would probably prefer that "NO JS!"). We've all gotten used to how the site works, we ignore all of its issues because we've adjusted our habits to work around those issues.
And I'm not saying HN has terrible UX (there are actually many things we can learn from it) but it's definitely not the site I reference when I need inspiration for a good experience.
I would disagree that UI constantly improves, though. I can think of lots of examples where the opposite is true. But that's not due to rapid release, that's due to other issues.
> If you go slow, things don't change as much but they don't get better much either.
It's hard to think of when I've seen improvements that were so good as to be worth the cost, though. Things certainly change, but change is not always better, and even when it is, it's not always worth the cost to the user.
Decades of “experimentation” have not improved the act of typing out a document in any meaningful way. Now, they have improved the experience for the corporations who can profit selling out their users data to the highest bidder and locking them out of their own devices while charging a subscription fee.
Chugchugchugchugchugchugchug
Watch icon
Chuchchugchugchugchug
Disk eject sound
Please Insert the disk ‘Docs 1’
Clunk
Watch icon
Chugchugchugchugchug
Word count: 2351
More responsive? No. No it wasn’t. Disks were slow. Memory capacity was low. You used to have to use third party RAM disk software to complete some tasks in a reasonable time. Or install a ram doubler to let you work on reasonable sized documents at the expense of slowing your machine down even more.
More intuitive? Hard disagree. The example I gave above was of getting a word count. You had to find the menu option to do that - it wasn’t just visible on screen. Same with spellcheck. Global search and replace was slow and clunky and felt risky. You only had one level of undo.
Faster to startup? Hells no. Again, slow disks.
More reliable? There was no auto save. Everyone who used a computer in the 90s has a story of losing hours, or even weeks of work to a crash. Everyone.
Easier to learn? Learn how? Word came with a few hundred pages of dead tree manual, but if you were on an institutional machine or running a ‘borrowed’ copy you didn’t have that. There was no internet to look up how to do stuff. Maybe you could pick stuff up from the tips section of a magazine? Sure. It was super easy to learn.
Compared to all of which, google docs or Word365 is just… light years ahead.
Most changes to already functional software are just changes. They aren't improvements or regressions; they're just making things different.
But yes, if you are regularly changing your UI in order to improve your system and roll out changes, you need to validate the impact. When I was last a PM, I spent a bunch of time monitoring the rollout of changes via Pendo to understand BOTH, if was getting the adoption of features I expected from certain cohorts and seeing if there where any shifts in user behavior (either organically, due to intentional or unintentional changes) And we did this for "beta" groups as well to really validate that feature were working with early adopters before broader rollout. I guess you might not consider the later "production" in sense, but these were real customers with real workloads.
You'll be able to find examples such as that, sure. But that doesn't make it generally true.
CounterCounterPoint: If the software was perfectly functional two years ago, all that can happen with a change, any change, is to make it worse :-)
In my experience it feels about 50/50 for better/worse, whether that is features taken away due to some business concern, blatant contempt for existing muscle-memory, or misguided designers reworking things that did not need a rework.
Given the tone of the message, I expect "non rapid" to mean with a much longer time frame, and, most importantly, the release must be controllable by the user.
This is pining for a world which no longer exists, because security patches must be applied to anything that matters immediately.
Of course you do need a strategy for maintaining multiple versions of something in that case instead of just forcing the latest version of everything you do on users whether they want it or not. With the lock-in effects of the always-connected web applications of today we all know which option makes more money.
I take some comfort in knowing that eventually most of the developers that force unwanted changes on their users will probably see their market share erode and lose their dominant positions. It's just unfortunate that we have so many quasi-monopolies in both essential and niche software products that it's going to take a long time for that to happen.
This world does in fact still exist, this is how most OSS works!
CD is a deploy strategy saying the aspiration is to do one deploy per commit, rather than batching commits and deploying once per N weeks or whatever. It has approximately zero to do with UX and product design/iteration approaches.
If you're not familiar with the general arguments for why CD might be desirable, a good place to start would be the books Continuous Delivery [https://smile.amazon.com/Continuous-Delivery-Deployment-Auto...] or Accelerate [https://smile.amazon.com/Accelerate-Software-Performing-Tech...]. The TLDR would be that most deploy problems in practice turn out to be because the process is manual, infrequently-used, and/or unreliable, and by practicing "if it hurts, do it more often" you are forced to iron out those kinks. For example you can't deploy automatically without a good acceptance/smoke test suite, and without solid DB migration testing/linting/practices, to name just two of many. You could just build all these things without trying to do CD, but in practice it seems that it's quite hard for organizations to prioritize this work in isolation, and the goal of CD seems to provide a fairly clear map to a much higher-quality deploy process. The practice of deploying more frequently to flush out issues, is also quite unintuitive as you note.
Here's a (probably out-of-date) article on how FB did deploys in 2017: https://www.infoq.com/news/2017/09/facebook-release-scale/ -- batched commits and staged canary rollouts automatically cut and released every few hours.
If you have external contracts that are onerous to validate then it can be quite expensive to build high-fidelity internal representations of those contracts. Could still be ROI positive to do so!
In most cases the contracts are either internal or simple (non-temporal) external contracts like a REST API, so most orgs benefit from moving in this direction.
We came from very different lands I guess. Batching 50 commits with no easy way of knowing which commit caused the issue seems scarier to me, in case of an issue. And if you code correctly and have warmup requests, your deployment could be without any downtime. Obviously there will be some extra resource usage because of unready resources.
Doing this in production is being disrespectful of your users. Users are not waiting for your PRs to be approved and merged, they can be as delighted by your new button’s shade of lightgrey if it is released some days (even weeks !) after.
The connection is that if the commit changes how the product works in a way noticeable to the user, then the user must suffer the changes frequently. Since changes incur a cost to the user, it's requiring the user to constantly be paying those costs.
If the deployment happened less frequently, then the user would incur the cost less frequently, and perhaps in a way they could schedule when to take the change on so it is the least disruptive to them.
Most software nobody cares if it works or even is possible for untrained humans to use, and it shows.
1. Release often
2. When a release goes badly (and they will) do some version of '5 whys' and fix the root cause.
3. Continue to release often
That step 2 is often missing and what usually happens is that no engineering time is committed to the solution. Instead they implement more process which costs nothing, doesn't solve the issue and slows development.
Just this summer, we went through these bugs one after the other:
1: Putting the ATV to sleep after finishing a video results in in a black screen with the video's audio playing from the beginning. This can be rectified by backing out of the video.
2: Putting the ATV to sleep while watching a video will cause the video output to freeze for 10 seconds or so when the ATV is turned back on. Eventually tvOS recognizes the app as unresponsive and kills it.
3: "Right" on the circle pad can no longer open the subscriptions tab, even though it still works on all other tabs. You have to use the center button.
4: When starting video playback, the first several seconds of sound are cut off, requiring the user to rewind if they contained anything important.
I don't think any of these issues existed simultaneously. Issue 4 started happening with the exact same release that fixed issue 3.
New releases should almost always only add features or fix bugs.
though looking at the history the number of recovery (point) releases have increased a lot
That's one of the many advantages of desktop apps: unless it's a bad player that forces the update down your throat, it is you who control if and when to upgrade, not the vendor, who may or may not have their interests aligned with yours.
(It's a bit similar on the mobile if you disable automatics updates, provided that you can ignore that obnoxious red dot forever.)
No one is going to say No to something new and sexy, especially not the customers (since we won’t ask them).
The trick would be giving users more distinct choices. For example, with something like Chrome the choice is between extremely frequent and just plain frequent. They don't really offer any long-term version.
This used to be a endemic issue for the mobile apps. And now even the desktop apps have started doing it. I am looking at you web browsers.
I’ve been working alone for 12 years and all those concepts were already working in the last large corp I was in.
What trends am I missing by being disconnected from the employment market? Am I missing anything or do we still develop like it’s 2010? Is there no new process or evolution on the style of management of software? Is Agile the final form of product management?
But they don’t seem as earth-shattering as missing the Agile boat.
From the article:
If I were to generalize, I’d say most of the companies I’m picking on fall into one of two categories:
They believe in DevOps ideas, but they’re unwilling to invest in changing their ways.
They aren’t convinced that some of the scarier ideas (like deploying multiple times per day) will help after all.
I’ve been thinking that UI changes should follow something like semver like APIs. UI is a contract between you and your users and completely shifting layouts should be seen as a breaking change.
These breaking changes should be avoided more critical the product is. E.g. health management app for elders.
And so there is no “staying on windows 7” for SaaS.
What would address my concern is if it were possible to skip releases, however rare or common they are, as I wish. But that raises an entirely different Bad Thing in the modern software industry -- that security updates are increasingly inseparable from other updates.
A lot of places just don't have the ability to maintain code quality requisite to do the process properly.
Rapid release means I can no longer rely on the software that engages in it. It's constantly shifting, with frequent changes in UI and workflow, and new and exciting bugs constantly appearing.
I miss the days when I could plan ahead for new versions, so I could time them to have the least possible disruption to my life.