Work in semi-related process automation, and this. So much!
Software engineers can't begin to understand what happens when you change a hotkey, when someone has been doing something 100 times a day for 10 years.
Work in semi-related process automation, and this. So much!
Software engineers can't begin to understand what happens when you change a hotkey, when someone has been doing something 100 times a day for 10 years.
E.g. It is well understood that users rely on a hotkey "a lot." It is not understood that users are so familiar with a hotkey that, if you relocated it on the keyboard, productivity would decrease 40% for 3 months.
That distinction is fairly important when trying to decide whether {new feature X} is actually worth disrupting {old feature Y}.
--
[0] - Almost everyone who spent most of their day job using a particular set of software tools quickly becomes a power user of these particular tools. The corollary to that is that if your software is the kind to be used at a job, it better be power user friendly, or you're going to wasting your customer's money and the life their employees.
It's been my experience that you get crappy software, produced with great effort and much gnashing of teeth, if your developers don't know your users.
Most of the time I experience a scenario of the engineer or support person saying "Show me what you are doing" only for the user to show some weird and non-logical (to the engineer) way of doing some task, and the engineer or support person replying "Well you should be doing it this other completely different way"
Product designers on the other hand.