My grandfather told me a story (perhaps apocryphal) of a final exam he took in a college Philosophy class. As he told it, the professor walked in, grabbed the chalk, and wrote "WHY?" in big letters on the board. He then sat down without saying a word and began waiting for the students to turn in their essays. Around the auditorium, students began scribbling long treatises on creation and existence. As the allotted time expired, many students were scrambling to tie up their arguments. When the tests were returned, the only answers that received full credit simply were "Because," or "Why not?"
The moral I take away from this story is, "Make sure you understand the question being asked before you supply an answer." It seems pretty straightforward, but this maxim is particularly useful to remember in the fields of design and usability. All too often as designers (and even more-so as UX professionals) we find our clients and ourselves answering questions that haven't been asked. We shadowbox with nebulous requirements and propose solutions to problems that don't exist.
One of my favorite examples of this is from back in the dotcom heyday. We were developing an online collaboration site for metal fabricators and their customers. Basically, customers could log in, spec out the fabrication they needed, and any number of metal fabricators could propose to do the work. One of the tasks in front of me was to add a weather widget to the user's portal home. When I asked why we were doing that, the response was that "the users may want to know what the weather is going to be." I replied, "Won't they just go to weather.com to find that out?" I was told that the people we were building this for don't use the internet. I guess that turned out to be true because the site didn't last terribly long. There are a number of cautionary tales built into this story, but they all stem from asking the wrong question. Instead of asking whether the weather, we should have been asking if we should even be building the site. Or, if we were going to assume the site would be built, how we would get metal fabricators and their clients to use the site.
There's a tool that's useful for just this purpose: the Scientific Method. The Scientific Method, in basic terms breaks down into four steps: state the problem, form a hypothesis, make a prediction, and test your predictions. In most situations gone wrong, I've seen the team jump to step 2 and never make it past step 3. This is usually accompanied by attitudes like, "We're all smart people," and "We'll know if it's not working." The fact is that even the smartest people will be off the mark with their educated guesses if the problem isn't stated clearly enough and, unless you test your predictions, you may notice something not working, but you won't understand why.
Of all these steps, clearly stating the issue you're trying to solve is the most important - understand the question before you attempt to answer it. Fortunately, there are tactics to help the UX designer state the problem with a great deal of clarity. Ethnography, competitive/comparative analysis, heuristic evaluations, personas, and Indi Young's Mental Models are all tools to increase the resolution of your problem statement. The more data points you have, the greater the fidelity of your model of the problem. It's easy to say, "We need a more dynamic site that creates stickiness," but without understanding the who, what, when, where, and how of your site usage, you'll be shooting in the dark. This will seem like common sense to the UX practitioner, it bears stating that your site is the mediator between your goals and the goals of your users. To state the problem clearly, you need to articulate your goals, understand the users that will help you accomplish them, and define the goals and tendencies of your users in order for you to form a hypothesis how you will enable the user to help you accomplish your goals by accomplishing their own.
All of these steps set the stage for more effective design. A clearly stated design problem allows for more focused design activities. Once you can articulate the problem you are trying to solve, you can form a more educated guess regarding a solution and can make more accurate predictions about how the solution will address the issues. Following with real testing will allow you to see if your predictions were correct and, more importantly, in what ways they were incorrect. As a result, you can refine your problem statement, take an even better educated guess, infer more accurate predictions, and validate the results through further testing.
Design, like Science - like Art, is a dialogue. The better we understand the question being asked, the better equipped we are to provide an answer.