Recently at work, I was describing what a client wanted to a designer, and I said "let me take a look at what you've got so far."
His reply: "No, 'cos then you'll give me design input, and what I want is information."
While it was a small blow to my ego (I thought I was an awesome dev-signer!?), I completely understood. We're often in a similar situation as developers, when clients try to tell us what they want built. Inexperienced developers may be inclined to go along with it and just build what the client tells them to - but that's a mistake. Instead, that's the time to say "first, forget what you want built, and tell me only about the underlying problem you want to solve."
Understanding the underlying problem, your job is to then guide them through the steps of defining the technical implementation, suggesting different options, letting them know about any trade-offs, weighing up cost/effort in vs result out, flexibility for the future, and letting them know about which decisions can be easily changed later, and which will be a nightmare. And, most importantly, mining them for information on all the complicated edge cases they require a solution for, which will significantly impact the implementation, but which they will no doubt have overlooked.
Ask first for information. Then, move on to implementation.