User-focused development

Examine, if you will, the core design, development, and support trio of a company’s flagship product. This trio considers the product’s users dumb and stupid and “fucking retarded”. They’ve been told 30 times that a date looks like 3/19/2008, not 3/19/08, and certainly not “next Thursday”. They’ve been given the manuals and a tour through the product. They must be retarded if they repeatedly break the software.

Customer support is, of course, a supremely annoying job. The customers don’t know what they’re talking about, and almost everything is a training issue.

But those users keep that company afloat and its employees able to eat. Their needs are simple, and many are easy to ascertain: they’d like for places where they put in data to gently remind them of when they do it incorrectly. They’d like the system to, if/when it fails, to fail gracefully and with a helpful message. They’d like consistency in navigation, and ways to do common tasks in their workflow with a minimum of steps and mouse clicks.

But if the customers are “fucking retarded”, their requests for help are best put aside until coding is done on this or that feature, and their needs irrelevant in the development of the software…

Who exactly is this software made for?