Listening to customers

Companies like to listen to their customers, so when a customer asks for a new feature, it often gets implemented in the next release of software. The customer is happy, as they've got what they asked for, and it probably makes their life a bit better. However, this shouldn't be done blindly.

Jon Kern has a blog entry on Stupid GUI Designs, starting with a comment by David R. on the stupidity of a "Do you want to exit?" dialog, and proceeding to rant about the things you can do in a "Save" dialog. There has probably been some customer, somewhere, who's actually asked for many of these features, and the development team have just blindly put them in.

It's not that I don't think we should listen to our customer's requests; on the contrary, I think we should listen very carefully, and ask more questions. We shouldn't blindly implement the solution that the customer proposes — we should find out what the problem is, and provide a clean solution to that.

In the case of the "Do you want to exit?" dialog, I recently had to implement such a dialog, because the customer asked for it. I should have dug further, and identified the problem. It was probably related to the customer accidentally closing the application when trying to do something else (such as close a maximised MDI child window — the two buttons can be very close together), and thus losing work in progress, and then having to restart the application, and spend time getting back to where they were. Maybe a better solution would be to provide an automatic recovery mechanism (like the SessionSaver extension for Firefox), so if the user accidentally quit, then they could resume where they left off just by restarting the application, complete with the same open documents, the same changes made, and full undo history.

Listening to customers involves more than just doing what they say they want; it means working with them to identify their needs, and produce software that satisifies those needs. It might take several prototypes to get there, as the shared understanding of the underlying need can be hard to build, and they aren't always aware of what is possible. This is a good reason for using iterative methods.