Listening to users and finding the problem.

Listening to users considered harmful?. A really great post with lessons from another industry, but ones that can be applied to any industry.

This doesn't mean that you don't listen to users--because the truth is embedded in what they say ... but you have to look for the deeper meaning behind what they ask for [...]

I've droned on about this topic for many years to anyone who would listen. Since "becoming" a software developer in 2004 I have been given a lot of contradicting advice on how to treat customers/users regarding internal systems, software and general support enquries.

The general consensus is the that the client is always right, they are experts in their field and we should make software that they ask for and move on.

Experience tells me otherwise. Clients may request specific features be added to a piece of software, because they are trying to solve a specific problem. This problem, however, may have many solutions with differing results. Diving deeper will help tease a better solution out.

Lee Munroe has a nice post about diving deeper into the problem by asking "why". Ask your client "why" 5 times.

[...] make sure you understand the root of the problem and explore all possible solutions before time and effort is wasted.

The customer (read: user) doesn't always know what they want and the developers first instinct should be to understand the underlying problem, rather than getting started on the "solution".

I have always found spending time with the users as they use the system can be very useful for seeing how they use a system, which can be vastly different from how they should be using the system. By learning users habits and techniques for accomplishing tasks, we can really understand how to develop simple and intuitive tools to help them solve real problems.

Always ask why. It can't hurt.