Doing both is probably the best. You need to talk to user to know what user wants and what problem you’re solving. But to know how users use their computers and how do they manage problems you software is supposed to solve now, it is better to watch them. If you ask me how do I interact with my computer every day, I am not sure if I could describe good enough for it to be usable.
I remember good example of this. One of our opeartors was reporting problems with one of our kiosk apps. A lot of app crashes and corrupted local SQLite database files. It was obvious “something” is damaging files in fs. We dismissed usual suspects (virus, bad hdd...), but it didn’t help. We even rewrote how we handle corrupted db files - didn’t work. In the end tech guys went there, observed how local operator operates the machine. It wasn’t surprise when they reported operator was shutting down machine by unplugging power cable from the wall. Operators never mentioned that, because they took it for granted, and figured out it’s trivial and not important.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.