Website sepcs for developers?

[Westech]

For the first time, I'm attempting to have some new sites completely designed and developed by a 3rd party developer. They'll be handling all aspects of the design and programming.

I have the general ideas in my head of how I want them to look and what I want them to do, but I'm having trouble documenting what I want in a detailed and organized way. So far I can see 2 options:

--Use a program like Visio to make detailed sitemaps, flowcharts, etc.

--Send them a huge Word file with a ton of bullet points.

How do you present your plans to developers? Is there any particular software or methods you use to organize and document what you want? Any tips for me?

[Chris]

I'm never so organized.

[KelliShaver]

Most of the people I do work for just.... talk to me. I'll occasionally get a TXT file with features listed. They tell me what they want, we toss ideas back and forth, I'll write up a spec sheet, we go over it and revise as-needed, then they sign off on it and I get to work.

[demosfen]

--Send them a huge Word file with a ton of bullet points.

Yes, that's what I do. A very detailed and clearly written description. Takes me a long time to think it over and to word it so that any major misunderstandings are avoided. Usually very few questions arise. Still, I agree that when possible, it's ideal if you can sit down with your coder and go over your plan. That way you can verify that he understands what you want.

[AndyH]

I'm with Chris on this one. Is this a site like the one you PMed me about?

[Westech]

No, it's not the one I PMed you about. I think I'll be pretty particular about that one and probably end up coding most or all of it myself.

[Sagewing]

In most cases, the more time you spend documenting your requirements the more benefit you'll get. Obviously there is a point of diminishing return - but it takes some time to get there.

documenting requirements also gives you a chance to think through all the little details, so that you dont' have to make hard choices along the way. Write up a draft, then keep expanding and expanding..

[Cutter]

I saw an interesting blog post about this a while ago, just rememberd it:
http://www.nevblog.com/2006/06/outsourcing-lesson-examples.html

I usually do the same, photoshopped concepts with notes.

[Sagewing]

I get jobs in that format all the time, but we usually convert them into a more wordy document, and about 10 times the length for internal purposes. There is just no subsitute for lengthy prose, and 'getting it right the first time' is how we maintain our profit margin and client substitution. Even if the client produces a weak specification like the ones on that blog, we can ordinarily do a 30 minute phone session a flesh it out nicely.

I strongly disagree with his comment about bargaining with developers from developing nations. If you have to treat your developers this way, you are bottom-feeding and should find more professional developers.

[Westech]

Thanks for the advice, everyone.

That blog post was very helpful, Cutter. Thanks!

[MarkB]

Don't spend too much time on bullet points, spend time on getting your developer/designer to do up mock pages (of all areas, especially user interaction areas like forms) so you can be sure they know exactly what you want before they write a line of code. Working from bullet points will never be as a good as this.

[ses5909]

As someone who is a developer I can say a good outline is a great thing to have. It leaves a lot less room for confusion. If I have a client that just "talks to me" I will write up the outline and include that in the contract. That way the client is sure he will be getting exactly what he wants and I can protect myself from requirements creep.