When they tried to demonstrate the bug, it was immediately clear to me what the issue was. That was the first time I really grasped the difference in how we approach software products. It also helped me see how the product could improve their job by watching how the process was in real life. Gave me a lot of ideas on how to make their job easier by using the product.
Just seeing the moments of hesitation, how the mouse is moved while searching in menus, etc gives me a lot of information.
Even if I show them a couple of times, it is often quickly forgotten.
For me as well. I've started my "career" this way, building something very specific for a client (family member) whilst being on prem and having constant and direct feedback, so that's how it was done I thought.
Almost twenty years later, having worked different roles with teams in office and remotely, I have to remind myself, and others around me, that we are building something to be used by real people with real problems and my/your software must not be one of them.
Never before have I heard such a good argument for formalizing the job. If architects or civil engineers were to do the same we had building collapsing left and right.
Every software engineer worth their salt has a certain degree of pride about doing things well. If this only ever is about the code, the commit history or other abstract concepts, but never about how well it can be used by the actual people it was made for, then how would they even start caring?