Assuming most HN readers don't need this advice for themselves.
But if you disagree with it or think I left out something important, please consider leaving a reply in the comments on that page, so future readers will see your suggestions, too.
The way I was taught was to start by hiring several designers to design every screen, and then only hire programmers after you're completely satisfied with the design. The way these outsourcing firms get you is by offering a cheap bid, and then charging you every time you want to make a change. So start out by knowing 100% what you want, and then once they've accepted the project don't let them ask any questions or make any suggestions until 1.0 is completely finished. (If they don't understand something they can ask for clarification, but that's it.)
Always have your fights up front, never once the project has started. That way you'll get the project on time and under budget.
I totally disagree, get basic stuff done by the designer, but I find it completely changes as programming happens. You figure out things won't work the way you thought they should, you figure out better ways, etc. Get wireframes down, so you don't spend thousands on designers, and then realise you have to spend thousands more.
Right get the UI right and it won't cause as many iterations on the back end (where it hurts more) as well prototype the whole UI in HTML/Javascript, Flash, Desktop app, whatever suits your fancy. Have a fully functioning UI that the user can touch and feel before you develop the back end. This will flesh out all data requirements and business logic services that will be needed to support the UI.
I am a little leery of not allowing the developer to provide input though. Things are going to change, you just want to narrow those changes to the important things.
I don't think you need a finely polished UI to start with, but some wireframes or even hand sketches of what each page/screen/dialog will look like can be a very effective communication tool. Written use cases are great but a picture can truly be worth 1000 words.
End users think in terms of screens, if you can provide them with a fully functioning ui then you can get valuable feedback about useability up front. The client knows in short order that they are getting all of the features they want because the get to touch and feel the system. After I adopted this method my project change orders slowed to a trickle.
The verbal narrative seems like a pretty exhaustive way to go. With something like OmniGraffle (or something like it) and a few accompanying paragraphs, you could describe the interaction a lot more clearly.
Also, I think it's a good idea to invite feedback. i.e. "Here's the spec, but it's flexible. As you read and develop, be noisy if you have some ideas that could make it better."
A lot of the commenters here are advocating "give devs a vague description of goals and turn them loose". I think that's a pretty bad idea unless the product/problem is a simple/obvious one to solve OR unless the the developer has a good understanding of the market.
But even if the dev is a young superstar who has NO empathy for the customer of your revolutionary manhole cover design workflow software, you should be open to feedback.
But if you disagree with it or think I left out something important, please consider leaving a reply in the comments on that page, so future readers will see your suggestions, too.