Any experienced architect will tell you only a foolish person would build a house without first putting some specs down on paper.
A website is no different. It takes careful planning and precise information architecture before you can hammer that first nail, or in this case punch up that first string of code. And because search engine marketing success is so critically dependent on having a website with a solid underlying foundation, future efforts to optimize are riding high on your ability to deliver a cohesive plan today.
A successful website deployment depends on creating a detailed specifications document, just as the house you live in began on paper as architectural blueprints.
Fail to plan, plan to fail.
Whatever we do in life, it is important to be clear about what we want to achieve. Otherwise, we never know when we’ve reached the end of the road. Same goes for your website. Before you begin scripting a “spec doc”, learn as much as possible about the visions and goals for the website.
This can include formulating thoughtful questions that provide relevant insight, creating an in-depth study of the current website and the sites of any potential competitors, and a good old-fashioned brainstorming session with members of the design and development team is always helpful.
The snowflake effect.
A spec doc can be long or short. It can be filled with dazzling bar graphs and glossy photos, or stuffed with plain old text. An ecommerce site planning to sell only two or three different products will probably only require 15 to 20 pages worth of your ideas. A large ecommerce website design or news site might look like the manuscript version of “War and Peace.” The point is no two will be alike. Every one is different.
However, stick to this basic structure and you should be fine:
- Purpose of the document
- Description of the project
- Front-end functionality
- Common features
- Sitemap and website structure
- Description of every website page
- Wireframes (home page and at least 2 other important pages)
- Miscellaneous functionality
- Back-end functionality
- Use cases
Delivering the deliverables.
A well-crafted spec doc allows designers and developers to move forward with a project while avoiding any surprises for the client down the line. It should give precise estimates of the time it will take to complete the project This helps control the scope of work and to keep costs from increasing during development.
7 killer tips for a successful specifications document:
1. Time spent on the spec doc should be proportional to the budget. Find out how much time is allocated to the spec doc and how detailed it should be. For example, 15 to 30 hours might be enough for brief document (15 pages and 3 to 4 wireframes), but a more detailed work takes no less than 50 hours. If the project has only 400 hours allocated, it doesn’t make sense to spend 100 hours writing the specs.
2. Don’t dive in head first. Before going into detailed specifications, spend some time thinking about the new website, drawing its structure, and drafting wireframes for the most important pages. Only start working on the specs when you have a clear picture of how the website should work.
3. Home is where the start is. For wireframes, start with the home page. It usually includes links to all important sections of the website, so if the wireframe of the home page is ready, it is easier to work on other sections.
4. Understanding is in the details. If you are working on the redesign of an existing site learn how all sections of the old website work. You’ll be happy you did later. If old sections are cut or left out, the corresponding or replacement sections on the new site should be noted. This is also important when redirecting old URLs that may be linked to from outside sources.
5. Not making a decision is a decision- a bad one. Do not leave empty sections “to be decided later”. Make sure that the spec document covers all website sections. If anything is not clear, come up with the questions for the client.
6. Make the possible, possible. It is important to make sure that all functionality described in the spec doc is actually feasible. Empty promises lead to hard feelings.