Holy cow, I wrote a book!
A common obstacle when trying to help people solve their problems
is that what people ask for and what they actually want are not
always the same thing.
For technical problems, you often get a question that
makes you shake your head in disbelief,
but upon closer questioning, you find that the person really
doesn't want what they're asking for.
What they really want is something else, but they've
already "solved" half of the problem and only need your help
with the other half—the half that doesn't make any sense.
For example, the literal answer to
"How do I write a regular expression that matches
everything except XYZ" is often a horrible mess,
but if you dig deeper, you'll find that they really don't need
a regular expression that matches everything except XYZ;
they just simplified their problem to
"I know, I'll use regular expressions"
ended up creating a bigger problem.
(The best solution is often a mix of regular expressions and
simple program logic.)
This problem also exists in user interface design.
Rick Schaut describes one case where a user asked for a feature,
when what they really wanted was an entirely different feature.
Understanding the customer's problem is the first step towards solving it.