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.
Comments
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.