When a user can’t accomplish his goal quickly and efficiently, the most natural reaction is surely “I wish this would just …” or “They really should add a ….”. And rightly so, as a good application should be clear in it’s form and utility. The same goes with clients. Problems usually come in the shape of “we have to add a … immediately”.
In both cases, users have failed an objective, and they’re expressing their frustration in the form of new feature requests. Most of the time though, it’s not the functionality which is failing, rather the presentation. A user-on-a -mission has user-goggles on, and they probably flew right past the signs the developer left for them. Oh, and the developer-on-a-mission has developer-goggles on, too, and may have simply forgotten about the user altogether.
My take is that more education will solve the problem better than more software. Using more coherent directional language in the UI or, quite literally, speaking with a client or customer over the phone will quickly get to the heart of the problem without any new coding. 37Signals has been the crusader of this approach since forever, shunning the 1000’s of ‘you guys should really add a …” type requests in favor of proposing how the user might accomplish the same goal with the current feature set, albeit with a different approach. It’s similar to the way talking about a problem makes you feel a bit better. Communication is key.
How to tackle this with a client? The most important step is to figure out what core business objective isn’t being met. Don’t talk in terms of new pop-ups or dropdowns. Talk in words. If this app were nothing but paper with words on it, what are those words not making crystal clear? Then, decide whether the existing functionality can actually serve that objective with a few UI or language tweaks. Would clearer wording on the page sell the feature better? Is something in the UI obscuring the utility in some way you didn’t intend? If nothing else, step outside yourself and recall what one dutiful DoneDone customer reminded me once,
Don’t assume that people are only going to use your application the way you think they are.
You may end up coding something new and different after all, but pausing to consider the above before diving into programming will, I guarantee, surprise you with how understanding most customers are, as well as teach you over time how to avoid implementing solutions before you’ve identified the real problem.