We've been working on a rather largish site recently and over the course of recent weeks, I have been reminded of a lesson learned way back in my dark ages when I was designing desktop database applications.

When developing any application but especially a customized application designed for a specific person or company, it can be easy to confuse problems with solutions. In that database I designed so many years ago, the client had been doing things largely on paper for a very long time. By the time I came along they had graduated to using was really not much more than a spreadsheet on steroids. A very rudimentary database system some board member had created in her idle moments.

They had developed ways of thinking about their processes and data that had evolved over decades based on their paper system. And that was translated into the board member's simplistic application. Conversations initially involved them telling me very specifically what my new program needed to do. But as I would look into simply doing what they told me, I would find a number of questions that needed asking. And as I asked questions, they (and I) started to see that what they wanted was actually a solution to a more interesting problem and not at all the best way to address that problem. With practice and attention, it has become almost second nature for me to recognize the difference.

In Jen's soon to be published book (that I am tech editing for her) she uses what I think is a great analogy. If you tell your car mechanic to 'fix the brakes' that is exactly what they will do. But if your problem was that annoying noise you wanted fixed, it is entirely possible that the brakes had nothing to do with it.  And you will be annoyed at your mechanic for no good reason.