UsWare vs. ThemWare
Generally when I go talk to users, it is to educate myself enough to become a user like them. Then I can see what needs doing, what needs streamlining, reorganizing, rearranging, etc.
This brought to mind Eric Sink's claim that there are three categories of software:
The developer creates software. The developer uses it. Nobody else does.
The developer creates software. Other people use it. The developer does not.
The developer creates software. Other people use it. The developer uses it too.
ThemWare is how most software gets developed, with predictably disastrous results:
If I am building software that I don't use and don't know how to use for people I don't understand or even like, how good is my software going to be?
I probably see every feature in terms of how difficult it will be to implement, rather than how valuable it will be for my users. I probably find myself wanting to label or document the features using my jargon instead of theirs. I probably create features that are tedious or unintuitive for my users. I can't imagine why the user interface I designed doesn't make sense to them.
I've found that much of the best software is the best because the programmers are the users, too. It is UsWare.
It behooves software developers to understand users, to walk a mile in their shoes. If we can bridge the gap between users and ourselves-- even if only a little-- we start slowly converting our mediocre ThemWare into vastly superior UsWare. To really care about the software you're writing, you have to become a user, at least in spirit.
Consuming the software you're creating is colloquially known as dogfooding in programming circles. Unless you're (un)lucky enough to be writing software intended for other software developers, dogfooding can be a challenge. But it's worth it. Dogfooding keeps software developers honest. Why work against your users by producing ThemWare when you could work alongside them to build UsWare?