> Except unless you provide a contact information in the error dialog, the average user will forget what the message said when they close the dialog to contact support.This is true, even of other devs which is particularly annoying¹². But these days I have the luxury of not dealing with clients directly so can just close things with insufficient information as CNR and move on, and have the joy of colleagues who make better use of the brains they have!
Sometimes the only solution is ample telemetry and hoping that the user can give your a reasonably accurate time of the incident when making a support call so you can reference that information. Though this can't help as much with client side problems that block the telemetry getting through, what information you do get can help greatly with reproducing, or just walking through with reference to the code, the issue, to work out what has gone awry.
> I have come to believe that many (most?) engineers and user experience designers actually hate people.
While I do occasionally work on front-end matters I'm usually not a UX person these days³ so I can't speak from that angle, but yes I do dislike a lot of the general populous! I think the problems you describe come from a position of disinterest rather than hate though, and a sign that a more varied team is needed. You need someone who is passionate about providing a good UX rather than playing with clever things and making stuff technically work. You also need a culture of taking care over your work too rather than doing minimal happy-path testing then throwing it out there⁴.
> One of the most important things I've learned is that no matter "intuitive" the user interface seems to me
I can't remember who said it, but I've always liked the quote “the only truly intuitive interface is the nipple, everything else has to be learned”. As you suggest, it is important to try put yourself in the mind of someone who is hitting your work for the first time without any of your experience, which can actually be quite difficult to do reliably. The other difficulty is the range of users any given application might encounter: sometimes you have to balance guiding the inexperienced, without hindering those who don't want to be bothered, preferably without effectively having two complete UIs to maintain.
--
[1] being interrupted with “I'm trying to X and I'm getting errors” “What errors?” “Something about the database, I didn't take a note” (to which the answer is “well reproduce it and come back to me when you've got useful information”, but by this point I may have lost concentration on what I was working on).
[2] One of the most annoying people I've worked with once said in response to me asking for the usual details, in an exasperated tone, “you always ask that” - the idiot was well aware that the information would be required and got irritated at it being needed instead of actually bothering to note it.
[3] I used to do a bit of everything in smaller companies, as things have grown I've specialised more towards database work, and infrastructure to support other devs.
[4] Though we have a full QA resource, we spend plenty of time doing “devtest” and making/updating/checking automated tests. QA (or in companies without that resource, the users) shouldn't be finding glaringly obvious issues because I rushed through one test case and didn't even think about anything closer to the edges.