The problem with your approach though is that there is no such thing as 'a user'. There are so many different cohorts of users. In your testing workflow it seems you are only using hardcore users for it. People obsessed with your software (internal or beta users) before pushing it out to the masses.
How do you avoid leaving the other cohorts behind?
This seems to be addressed by one of my complaints. Was this feature not tested before pushed out to users?
I get that design is difficult. Anyone saying otherwise is biased. But it seems like a big problem is just trying something out first. Design can take months of use to realize something is bad. It seems like what should be done is: create new UI; use internally and push to everyone's version, use for a few weeks to a month; push to beta and get user feedback and pay attention to web traffic like HN and Reddit complaints about the new design; then decide if it should be pushed or not. I've seen apps that seem to follow this but just push despite bad user feedback and bad internal feedback. Going through the motions isn't enough, it has to be used as iterations.
> So you can't trust your intuition, you need to listen to users with fresh eyes. But they're also telling you 5 different, conflicting things, and if you listen to everyone you'll have a settings section 9 miles long.
A good piece of advice I heard was "listen to users for problems. Don't listen to users for solutions." Because people are actually really good at identifying problems. But most people are really terrible at solving problems (I mean if they were good at it we wouldn't have 90% of the problems we do). The addendum is to only take solution advice from experts that understand more of the nuance of what you're doing, but then to still be careful.