I have received a lot of e-mails over the years from developers who don’t quite get the idea behind application design. The problem is that developers are taught about tools, strategies, patterns, and all sorts of other technical details, but are never taught an essential lesson that all applications are essentially products and that it’s up to the developer to sell them. The societal claim that all developers are socially inept nerds who are incapable of communicating with other humans doesn’t help. The fact of the matter is that an application that doesn’t serve the customer’s need will never get used—it will never be successful. Developers need to get the idea that they’re creating a product that must satisfy customer needs in order to be successful.
Many applications today are akin to inflexible restaurants. Imagine how you’d feel if you went into a restaurant and ordered a single egg, fried, with white toast, and a side of sausage and the server says, “I can’t fulfill your order.” Your first question would be why the order is so hard and her response of, “It’s not on the menu.” takes you completely by surprise. It turns out that the menu specifies two eggs, not one. Many applications present users with precisely that sort of choice, yet developers seem surprised when users are less than thrilled. A response of, “It’s not on the menu.” was never a good or valid one, yet that’s the response developers have offered users for a long time now.
In order to be successful, an application must be flexible enough to meet user demand. A developer must understand the user perspective and create an application that can meet the demand for one, two, or even three eggs (or how many ever eggs the user wants). After all, it doesn’t matter how many of an item the user ultimately wants, as long as the user is willing to pay for those items. In order to gain that perspective, developers must talk to users, listen to what they have to say, and engage them in the development process. All other businesses that I know of engage their customers in some way to ensure their products meet customer needs and the computer industry must learn to do the same.
Many applications also make things entirely too complicated. It’s akin to going into a restaurant and not being able to order until you provide the secret handshake. Servers who say, “Talk to the hand because the head isn’t listening.” won’t stay employed for very long. A restaurant won’t stay in business very long with that attitude and neither will the developer. A user isn’t interested in the arcane science of development or how many cool widgets your application uses. The user is only interested in taking a picture or performing some other activity that has nothing whatsoever to do with development or even computers for that matter. As far as the user is concerned, your application should be invisible.
So, why my preoccupation with restaurants in this post? I was watching someone use one of those restaurant data entry programs this morning. After the server provided the secret handshake, she had to navigate no less than ten menus before she was able to complete the order, which then failed because they were out of a particular item. So, she had to cancel the order and reenter everything. Would it really have been all that hard to add a feature where the cook could simply tell the server that something was out of stock? Does an order really require navigation of ten menus to accomplish? It surprises me that this order entry system is actually installed somewhere—perhaps nothing better was available.
The day where a developer can offer inflexible solutions that don’t meet user needs and offer only complexity is over. As users become less interested in accommodating developer needs because there is always another solution to try, developers will need to accommodate the user’s needs. Actually, that’s what should have happened in the first place. No other industry would have tolerated what users have had to tolerate from the computer industry. Let me know your thoughts on gaining the user perspective at [email protected].
