7 Killer Tips to Creating a Website Specification Document to Support Your Search Engine Marketing Efforts

How To Write a Specifications Document

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
  • Conclusion

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.

7. We often do not see things as they are, we see them as we are. Avoid possible misunderstandings. Clients might be believe they understood what you said, but often they don't realize that what they heard is not what you meant.Most clients won’t have knowledge of HTML, JavaScript, etc., but you should still be able to make this document clear for him as well.

Subscribe to
Our Newsletter

Comments

  1. Bo Lora said:

    The problem with “spec documents” as well intended as they are, is that nobody reads them. Everyone always gravitates to visual elements and do very little reading.

    A developers is most likely to look at the comps and make assumptions on the other things. So all the time spend on functional requirements could end up as wasted effort.

    This is not a slam on developers, it’s just human nature to be visual. A picture does say 1000 words.

    We must find ways to mesh visual aids and “specs” to create an interactive model with all the requirements info in context. Programs like iRise and Axure have been bridging this gap we we still have a way to go.

  2. Alhan said:

    Although it is true that few people actually go through and read spec docs, they are essential when putting together a business proposal to pitch to investors. No one is going to put money into a website that is completely based on ideas. There needs to be a clear vision for a website laid out in spec doc format.

  3. Bo Lora said:

    I’m certainly not saying that specs are not needed. We in the UX community need to start thinking of new ways to represent ideas in a more interactive way rather than static documents.

  4. PO said:

    Thanks for the post. Spec sheets ARE important, and not only to big clients with big websites. Smaller websites need focus and direction too. There’s always a client who calls halfway through the process and says “hey, let’s ditch this flash based navigation system for unicorns” Hey, it could happen.

  5. Bo Lora said:

    These guys really nail it in the head for me: http://tinyurl.com/a4cabj

  6. Sadly it all depends on what the market is prepared to bear. It is one thing to build a website for a corporate – they expect to pay big bucks and to have time spent on documentation and specifications.

    Try that in the small business environment or personal website environment where each cent counts and they can always get a website for really cheap (obviously built by their neighbour’s son who ‘is so good with PCs’ in his spare time)..

  7. Guy Page said:

    Great comments. I like the idea of progressive visual specs. It’s so difficult to nail down everything on a large web site before the client knows what they want, and as PO said, once they start seeing it develop, it’s “hey, what about this?” So what about a “funnel spec” (like a sales funnel) — start wide and narrow it progressively to the final product. What would “wide” be? Attitude? Top level design? Key functions? Depth? UX? What do you think?

  8. John Paul Wlaker said:

    This certifies my hypothesis of services and decisions not anymore being either B2B or B2C and rather as H2H (Human to Human)
    Thank you Blue Fountain Media – this certainly helps as you can well see me, myself entrepreneuring my way into the Website designing and Digital marketing agencies.

  9. Pingback: Takeaway: Client work, Mission Statements, & Site Specs | IWC Takeaway Blog

  10. Pingback: Week 4: Marketing Plans and Mission Statements Takeaways | loriwc2014

  11. Pingback: 9/26/14 Takeaways | My Take-aways

  12. Pingback: Takeaways 7 | liebigiwc2014

Leave a Comment on this post

*
*