I think the developer really needs to know the details of the domain and problem space. The company I am working for is a workforce management consulting firm. The first week on the job I interviewed 10+ consultants with the company. Got to know their tasks, goals, accomplishments, needs and pain points. I also shadowed in on one consultant for a day, and read a lot of literature. I know an awful lot now what it means to do work force management and workforce management consulting. This is helpful, very helpful. I become a knowledgeable user of the very system I am creating. Imagine if Adobe's developers had no clue about image editing, Photoshop would have been a disaster.
This feeds into my other point. Don't give the developer detailed descriptions of every click, button, error, etc. Give them the exact opposite. Tell them what the system needs to accomplish, and let them design it. For one, they will almost certainly design a simpler and easier to manage system than you will (maybe not easier to user, because let's face it, that's not usually a programmer's forte). Since the developer now knows the domain pretty well, they can use that knowledge to help design an effective solution. let the developer arrive at your goal with as minimal amount of code and work as possible. That way you can see your vision in the flesh, use it, and actually start to understand what it does. Only once a feature is actually implemented and put to use do you really start to understand what it needs to do.
Maintain a dialog with your developer. Give feedback often and have the two of you work together on where the project is going.
Basically all I am saying boils down to what most agile development processes ascribe to.
I do however totally agree with doing the "simple" version 1.0 release first.