Just to reemphasize your rewording and redirection, the delays and paraphrasing that you mention are just the tip of that iceberg. In my experience, lack of direct contact with the actual end users tends to end up with the software being built to do what the end users' manager thinks they need (or, still worse, what the manager thinks they should need), which often has little or no connection to the reality of what the end users will be doing with it.
Design-by-management-proxy also tends to lead to the software being created solely to duplicate the existing process(es), but with newer, flashier technology, while allowing the developers to get in there, talk to the users, and actually gain at least a rudimentary understanding of not only what the end users are/will be doing, but also why will often allow for better processes to be developed. | [reply] |
I know where you're coming from, but I think we're in two slightly different situations here ... you're likely dealing with a case where people are forced to use the project. I've been in that situation, and people complain about what they don't like, but they might not send it to the right people, and might take days for it to reach the developers (if ever).
On my more current work, I'm building software that is completely optional. It's intended to help people, but no one's being forced to use it. When I built the system for Fark -- if people weren't happy, they'd leave ... we had no idea why, and really, we didn't care. (this was well before Drew was selling advertising) The submission queue was just to make it easier on the admin, so we could weed out the crap people were submitting.
Now, I'm working on software to help scientists find data. They have other ways to find their data, so most don't bother using what we have ... if they use it, and aren't instantly happy with it, they don't fill out the feedback forms or e-mail us ... they just go away. So, once or twice a year, I go to conferences to tell people about new features and try to get the scientists to tell me what they want as new features ... some aren't willing to tell you what they're looking for, as it might tip their hand on what sort of research they're trying to get funding for, others are just happy with their current methods and don't care.
... Of course, in some ways, I've probably harmed the users by taking to them. I tried sending out an explanation of what's wrong with some of the catalogs, and someone asked 'what's "normalized data"'? We speak completely different languages when talking about the same problems, but I can't design an interface for their use without understanding how they think about their problems and the words they use to discuss concepts within their specialty. But, anyway, I think jenda and I both agree -- developers and the users need to interact, so we can understand what the users want and can fix the problems they find.
| [reply] |
