A personal pet peeve of mine is that people sometimes ask rhetorical questions - rather than simply state what the problem is. Drives me nuts. For example: "Why doesn't this button submit the form?" vs "I don't think this button works". I see this all the time and still scratch my head.
There are downsides to saying “this button doesn’t work” — there’s a follow up question in some cases, which is “what makes you say it doesn’t work?” Asking the question acknowledges that there may be a lack of understanding of the intent of the button. Maybe to you it doesn’t work, but to the person who designed it, it is working as intended, and your mental model is the incorrect part. Asking the question as framed directly in the way you experience the world (action not leading to an expected reaction) makes the problem statement more clear.
What do you think is more reasonable? Asking hundreds of thousands of users to learn to give better feedback, or for hundreds of developers to learn better listening?
The problem here is a meeting of minds: The user can't possibly know what is expected behaviour, especially with the modern lack of GUI standards. A tester might be able to read a user manual, but the manual might be wrong. As dev, you're the vendor. Some maturity is expected and that you're able to figure it out.
What helps is reaching out to users earlier and agree on behaviour together. You know, using agility.
It’s a pretty sophisticated skill to hear aggression in others and be able to hear what is causing them pain instead of just “I wanna fight.” But aren’t we problem solvers by trade?
Problems make people upset. If you can only treat polite customers you’d make a terrible health care professional or even plumber. Someone once gave me the advice that part of why developer salaries are so high is because they include hazard pay.
I suspect the same is true for plumbers. $300 to get my plumbing unplugged on a Saturday night can probably smooth a lot of feathers with his family. And that was a slight discount, probably because I was pleasant, instead of railing at his whole profession for a problem he didn’t create.
It’s hard to remember this sometimes, but I do think it provides some perspective.
I actually think the tendency is to ask questions since they are simpler. It’s an extra leap to say “this button doesn’t work” because you have to make a judgment. On that note, sure, you can’t expect most of your customers to give great feedback, but that’s why finding those few customers who do is so rare and valuable.
I prefer the question. Saves me having to ask what they think it should do. "X doesn't work" often isn't very useful feedback in my experience unless accompanied by more detail.
You're highlighting that good bug reporting is also a learned skill. It is not sufficient to say button X isn't working. An experienced bug reporter will also include information on what the expected behaviour was, and often also explain what is needed to reproduce the problem.
It helps to explicitly ask about this from end users when you have a bug reporting form.
Except it's never learned. Most devs and testers absolutely suck at it, no matter how much training or long experience. Otherwise great people, but you need to put yourself in the role of the person receiving the bugreport. Most people don't know the tech too well, can't do that or forgets to do it very quickly. In the heat of the moment of deadlines, this is expected human behaviour, ie. optimizing locally.
I find, when there's no common context, I have to reach out and spend some time with the person anyway. Usually you gain new insights, relationships and improved common understanding. Feels almost humanizing and well worth the time spent.
If people say either of those the problem is with your product UX design in the first place.
There should be distinct progress indication for long operations and human-readable feedback for every failure mode, even if simplified, to avoid overwhelming users with difficult terminology.
Very often the simplified human-readable feedback is "Oops, that didn't work". And it is so simplified that there is no useful information to send to an expert for help. It is better when the error message is unique and can be googled (or your intranet equivalent)
It is perfectly fine to have "Oops it did not work, try again later".
Loads of error scenarios come up once in blue moon, details for those you should have in application logs that should be analyzed by technical support. Usually user cannot do much about those, like some service is down. Information about some specific service not working for users means your application is down, so it does not matter.
Then you have failure modes that happen often, like users getting data from outside system where your business rules do not allow for that data. In that case user has to be provided with information what he can fix, "Operation is not permitted because we operate only on yellow cars, buy a yellow car please".
In the end technical support should triage issues and invest time on specifying error messages that can help users skip technical support. It is a waste of time to come up with all errors explaining some details.
Personally I found no situations where oversimplified indication of failure is fine in such contexts.
If service is down users should know it is down and it is not a failure of their device or network connection. It is normal to skip specifics that developer need for debugging but simply indicating a failure will just annoy users because they won't know what they could do. And contacting support each and every time is tiring and counterproductive for everyone involved.
It can be error code or somewhat generalized textual description but it gives users feeling of control which most people like to have.
In my opinion that is perfectly good reaction.
If someone asks it shows willingness to solve the issue or understand the problem.
How do you know that this button does not work?
Maybe the form has some field that does not show validation message.
Usually when users say with confidence that something does not work, it turns out that something else does not work and that button they mention is perfectly fine. In most of cases users just expect something else because they don't understand the system.
Because pretty often there is a reasonable answer to that question - especially when you are seeing system first time and know that there is a lot you dont know about it.
