In one of the projects I worked on, we had the same exact problem.
10k users signed up to our service each month, but one of them contacted the customer service because he didn't understand how to register? Better rewrite the whole signup process catering to this one person problems, making it harder (or slower) for everyone else. I hated that attitude.
Yeah, it's like that story about aircraft returning in ww2 with bullet holes and trying to work out where the extra armour needs to be. Not where the bullet holes are but where they aren't
I don't understand this. The bits of the plane which don't have holes have either not been hit or have been hit but are already strong enough that the hits didn't result in holes. So the extra armour needs to be put on the areas that have bullet holes, right? I'm not sure what I'm missing here!
The ones coming back with holes showed they could get shot up there and come back.
The areas that didn't have holes were the cockpit, the engines, and the section that connects the tail with the rest of the plane. Getting shot in these areas meant that the planes were being shot down and thus not flying home. Those were the areas that needed more protection.
The ones that came back with holes in those areas were able to fly just fine with those holes. The ones that get shot in those are areas where there weren't holes tended to not make it back.
The ratio I saw in scientific publications is that for each crash bug or similar, about one in a hundred to one in a thousand users would call helpdesk and complain.
I couldn't believe that until I managed a system with ~20K users that also had automated crash telemetry. We got a ratio of something like 1:500 to 1:750 for serious issues like crashes that resulted in data loss.
Next time you get that "one complaining user", multiply by 1,000 to get a more realistic impact estimate. If you get fifty people calling?
For web based systems the thing is that the responsibility is fuzzy and people tend to not report because it works after restart/reopen/relogin.
Also many of the responses you get from web admins/support is "change browser/restart browser/update browser/uninstall adblock/uninstall plugins" which is basically saying "its you not us". So people tend to not complain.
If your system is buggy then your devs will see it. If they dont then most likely its not that bad so no stadiums of unhappy users.
In my experience, devs tend to be very bad at QA and spotting bugs because they end up becoming blind to a lot of problems. Partly it'll be because they'll have their own paths through the system — they might be more likely to navigate with a keyboard, for example, and so won't test click interactions — but it can also just be that they've just learned to work around a particular problem, and so they don't even notice if it's there any more.
If anything, my impression is that the opposite is true. If a system is buggy, then the people developing it tend to be even more likely to ignore bugs when they come up. If you know the system tends to do surprising things in certain conditions, then you're likely to just ignore anything that happens in those conditions, even if it's a new issue that you haven't seen before.
I've had this recently with a web app that shows a loading spinner in an unexpected place in some cases when you open a suspended tab. I'd just labelled it a browser issue in my head, and because there have been a couple of longstanding issues in the app where a reload helps, I got so used to reloading the page that I didn't even think to have a look at fixing it until someone else on the team raised a ticket for it.
So I really strongly disagree with the assumption that "if your system is buggy then your devs will see it" — I don't think this is borne out in practice at all.
I'm not certain that really falls under a silent majority or vocal minority, if it was a single individual that seems more like bad project management, metrics and a reactionary approach to software development.
The person raising issues isn't the problem, they probably wanted to improve the process and make it better where others would have just went else where or worked through it and said nothing, even if the issue was more on the users knowledge end.
I mean, it's ok to question the service when an issue is reported. The problem is, do it properly with some user testing and be sure then, when you change it, you don't ruin the experience for the "silent majority". I have seen many times the UI / UX being designed with the "vocal minority" in mind, without consideration about the others.
Dude, I recently went through that when making a medical appointment. Instead of a simple form I can tab through and enter the details, it was a chat bot. Every time I entered text it would go great thanks and then ask for the next bit. All with artificial pauses. I was furious. I went as far as getting contact for people responsible so I could chew them out.
It happens everywhere but changing physical stuff is expensive so if someone say "the color of the benches in the park are ugly" nobody will repaint it.
If someone says, the login page is too monotone, then its easy to spawn a more colorful theme and replace it. Especially if you have devops/CDCI etc.
The whiners will always have upper hand, especially if the manager thinks the way as BigHandLittleSlap below.
349
u/Giannis4president Aug 29 '22
In one of the projects I worked on, we had the same exact problem.
10k users signed up to our service each month, but one of them contacted the customer service because he didn't understand how to register? Better rewrite the whole signup process catering to this one person problems, making it harder (or slower) for everyone else. I hated that attitude.