Conversations, sitemaps and wireframes, oh my! Surely, it’s time to take all these wonderful things and build the darn web site already? Ah, if only… on the plus side, if you can hang on a little longer there will be the reward of a truly well-planned, well-organized and fantastically functional web site at the end. But right now you’ve got to take what you’ve built so far and add on another piece – the specification.
Step 4: Spec It
Ok, so this part is not going to be super fun, but it is super necessary. If you can make it through this step, you’ll keep your project on schedule, on budget and totally on top of the competition.
The good news is that if you spent enough time talking about your project and taking notes in the beginning, this shouldn’t be so painful. It does, however, require a pretty serious attention to detail.
The planning process is a little like that old song where the shin bone’s connected to the knee bone… and the knee bone’s connected to… um, something or other. Fortunately you don’t need to remember your anatomy but you will be building a connection with your wireframe, which you just built to connect with your sitemap.
Remember all those boxes you drew on all those pages to show what’s going on your site? Well, now it’s time to get into the nitty-gritty of how it will all work.
Spec The Photos
You’ve made space for photos, so now it’s time to figure out what those photos will be. For starters, will they be home grown or will you purchase stock photography?
Don’t get into the design and then wonder where the heck you’re going to get photos from. Decide how many photos you need, or at least a reasonable estimate, so that you can either get busy with your digital camera or set aside a budget to suit your needs. It’s not a bad idea to actually have those photos available so you can specify which ones will be used where and on what pages.
You should also think about size requirements and annotate dimensions right in your project spec. In some cases, you can get away with waiting until you get into the design phase, because your designer will have some ideas about how big or small your thumbnails, icons, standard sizes and enlargements should be. But the more specific you can be now, the less room for questions later.
This is especially important if you’re going to be buying photos, because you can buy them in various sizes, and you’ll want to be sure you purchase the appropriate size and don’t risk spending money on something too small to fit your space.
Spec The Functionality
So you’ve left room for the navigation menu, but how will it work? Will it roll down? Pull out? Will it do that on mouse over or click? Decisions, decisions. How about that awesome carousel you want? Will it change images automatically or wait for a visitor to click? Will it use page numbers or icons for scrolling through? How many seconds will each image be on screen? More decisions!
And don’t get me started on the Contact form! Dropdown menus? Text fields? Static questions? Dependent fields? How many characters? What information is required? In a recurring theme, decide now or repent later.
Unless it’s a block of paragraph text, you should be specifying exactly how it will work. In some cases, you had also better know what will happen if it fails. Any moving parts on your site, from Flash (what happens if a visitor is using an iPhone?) to video (will it be hosted on YouTube?) should be written down. On paper. It’s not good enough to talk about it anymore.
You need it clearly detailed so that when your developer gets to work there’s no question about what’s right, what’s wrong, how you *think it’s going to work or hope it will… it should all be clear as a crystal wineglass with as little room for interpretation as possible.
Spec The Technologies
Great, so you know how everything will work, now what technologies will you use to make it work? Notice how there was no discussion of technology before now. That’s because to a large extent, technology is irrelevant.
There are lots of ways to get things done, so don’t marry yourself to some technology that you absolutely must use (I want a Flash page! Love that JavaScript!) before you know what needs to be done.
But now that you know what needs to be done, it’s time to figure out how to make it happen. Lots of technologies can be used to accomplish similar ends. It’s now a matter of what works best, what achieves the result you want, what is most cost-effective, time-efficient and familiar to your development team.
You probably don’t want to be the guinea pig on the learning curve of some totally new technology just because you heard it’s all the rage. So stick to business needs and specify the technologies that will support them.
At this point you also want to know what licenses you’ll need to purchase, what accounts you’ll need to create or what steps need to be taken to implement your chosen technologies. This will save you a lot of nasty surprises later when you realize some fantastic idea is going to cost $900 a month in subscription fees.
Spec The What-Ifs
Admittedly, this one is hard to do. I’m asking you to think of all the things that could happen, things you can’t imagine happening… and imagine them. It’s a little like playing Devil’s Advocate to your own site. It could go a little something like this:
Developer guy: Your Contact form is done. It’ll be delivered to you via HTML email.
You: But what if the sender doesn’t include a phone number?
Developer guy: No problem, a JavaScript error will pop up if the field is blank.
You: But what if the JavaScript doesn’t work?
Developer guy: Well, we can change it to a more secure validation.
You: But what if the person includes a phone number without the area code?
Developer guy: We can force an area code.
You: But what if the person doesn’t know we want an area code?
Developer guy: We’ll put a formatting example next to the field.
You: But what if I never get the email?
Developer guy: We can set up a daily test to be sure the form is being delivered.
You: But what if it’s a spam message?
Developer guy: We can include a code validation to reduce the possibility.
You: But what if someone doesn’t want to give out their email address?
Developer guy: We’ll put your phone number there, too. Then someone can call directly.
It sounds silly and simple, but all of those questions can mean the difference between a successful customer contact and a total failure. And that’s only one silly and simple example.
A good developer will sit down with you and work through the what-ifs. So don’t be afraid to ask the questions and document the answers in your specification. No, you won’t be able to think of every possible scenario, but you’ll be that much closer to eliminating the roadblocks to success.
Depending on your site, a specification can be fairly brief and straightforward, or it can be pages and pages of details. An informational site will be easier to spec than one with a database, shopping cart and various interactions. But you won’t be sorry you did it. You’ll know exactly what to expect and your developer will know exactly what to build.
In the end that’s a win for everyone.
Have you ever started a web project without a specification? What was the result?
