Blog

What customers want

The key to a satisfied customer is to give him1 exactly what he wants and thus the first step in any project is to find out what this is. There's more to it than meets the eye!

The first challenge is the description of the problem. Whether using diagrams or natural language, there's invariably some room for (mis)interpretation. Developers may not always be familiar with the specific vocabulary used in the context of the customer's working environment while customers don't necessarily associate the same concept with terms which are obvious to a developer. It is therefore primordial to eliminate all possible ambiguities as early in the process as possible.

A complication arising almost exclusively when adapting or extending an existing solution, is that the problem description provided by the customer is not the description of the original problem, but the description of a problem occurring while trying to circumvent the original problem. If the developer has some affinity with the environment the customer is working in, he may detect this. This is not always the case, though, and the customer then ends up with a solution that allows him to work around the original problem in a very elaborate way while the solution to the original problem may have been easier to develop (and thus cheaper and less error prone). We actively avoid this situation by not only asking the customer what he wants, but why he wants it and how it's going to be used.

The last issue I'll elaborate on is one that's entirely up to the developer to come up with a solution for. It's this: one part of what the user wants may be hard to reconcile with another part of what he wants. The easiest example is probably wanting software to have lots of functionality yet be easy to use. All these possibilities have to make it into the user interface, making it a challenge to keep it simple and easy to use. The key here lies in knowing how, when and in what context this functionality is going to be used.

For these reasons, I rather ask some questions "too many" than one too little. The time "lost" asking extra questions is largely compensated by not having to start the project all over because of a wrong assumption made before the actual development process was started.

1 Throughout this text, "him" is meant as "him/her", and "he" as "he/she".