All software is developed to be used by someone, even if only in an automated fashion (that is, without any direct interaction with the user). As such, it is important to understand who your user is, or you may (ok, probably will) find the going tough. If you are a game developer, life is good. You know who your users are – gamers! Likewise, there are many industries or types of programs where the user is a well-known entity. If you write accounting software, for example, your user is probably someone who does…uh…accounting.
I happen to work in an environment where the real user of the software is often a bit of an unknown. Well, the real user is generally known, but often we are unable to get direct feedback from the user, or the feedback loop is very tenuous and arrives filtered through other people who generally are not developers and rarely elicit the right kind of feedback or ask the users the right kinds of questions. The situation can be so backwards, in fact, that some of the developers I’ve worked with over the years are convinced the user is, in fact, the middleman who filters all that rarified feedback. Developers will say things like, “I’ll have to talk to the users about that.” Of course, they’re never going to talk to an actual user, just the business people who are in control of the project. In the real world, these people would be called stakeholders, but even in other companies, I’m willing to bet that the stakeholders are actually treated as if they were the users.
Stakeholders may feel they have deep insight into how real users will interact with the software, but, unless they spend a lot of time with real users, they are typically just guessing. That’s bad enough, however, the real problem occurs when the stakeholder has a vested interest in trying to shape the software to make their own job easier. While that’s understandable, and their opinion does matter in that respect, it doesn’t serve the actual user of the software. A common symptom of this affliction are screens that fit the stakeholders workflow, rather than the end user’s workflow, or forcing the end user to enter all kinds of data that may not be readily available to them. The stakeholder wants every possible piece of data up front, whether they truly need it or not, and these become required fields. End users will frequently come up with creative ways to get around the restrictions, which ultimately helps no one, because it ends up being extra noise to filter out.
Unfortunately, developers have no say in any of this, and most will simply do as they are told. I’m not sure what can be done to change this attitude, but it’s ultimately counterproductive, and developers like that end up revisiting things over and over as they try to tweak things and plug holes – problems that might have been averted by paying more attention to making sure the software actually was developed for the right user.