Joy Of Code - Web Design Training and Consulting
Joy Gems Newsletter

Writing Design Specs For A New Web Site

By Bud Kraus
bud@joyofcode.com
Joy Of Code
Creator And Instructor

v3 i19
Originally Published: November 15, 2007

One of the worst mistakes you can make in developing web sites is to rush into production.  People naturally want to design first, and plan later.  Oops!  Not a good idea. They open Dreamweaver or Photoshop and away they go.  That's their first mistake and it's always their worst mistake.

May I suggest that you plan first, then design and produce.  Think about how movies are made.  How many times have you heard about the years it took before the first scene was shot? A long pre-production (development) phase is followed by an only 6 - 8 week shooting schedule. Once principal photography wraps, a relatively short post-production phase follows and the process ends prior to distribution (launch).

Faithful JG Readers may recall "Think Before You Code."

The process of making a web site begins with business planning (market research, financing, etc). Next is the design specifications which are the blueprint for what the site will be and do. You need to develop and commit them to paper (or screen as I do).

If you're outsourcing the work to a design studio, let them decide how it will look. That's their business.

Even if you're not outsourcing but instead, working with an inside team (and to me team can mean one person), you still need to do the specifications.

Just what should you include in your design specs? In what format should they be? Glad you asked!!

What To Include In Your Design Specifications

Web sites have two fundamental pieces - the front end, that which is downloaded to the user, and the back end, the programmatic elements of a site which remain on a server. Keep that in mind when describing what your site will be and do in your specs.

As mentioned, my specs are not suggestive of art direction typography or other style elements. The focus, at this state, is on what the site will be and do and not on how it will look.

Here's a real world example of an outline of the front end requirements (what the user sees) for a new site:

  1. Objectives
  2. Design Deliverables
    • Web Design Standards
    • User Agent Compatibility
    • Navigation
    • Branding Elements
    • Templates
    • Search Engine Optimization
  3. Site Map
    • Enrollment And Account Management
    • Product Descriptions
    • All Other Content
    • Global Navigation
  4. Project Timeline

As for the back end requirements (server side functionality), these are the main matters which need to be addressed:

  1. Hosting
  2. Content Management System
  3. Security
  4. Associates Program
  5. Site Search Tool
  6. Email Newsletter
  7. Other Programmatic Needs
  8. Site Metrics

Of course, these will change from project to project, but I favor the approach of dividing front and back end requirements in one's specifications.

Other documents can accompany your specs, but at this stage, it's a little too early to write the technical requirements of the site or Information Architecture documents.

What Format Should You Use For Your Specifications?

Use a format that you are comfortable working with. For me, that means writing the specs as a web page. The advantages are that I can

  • leave it online for competing design firms to refer to
  • have hyperlinks for reference material
  • easily convert it to other formats, such as .pdf.

But you don't have to do it my way. You can write your specs using Word, or even Excel for that matter. Have a diagram that is best done with Illustrator? Use it!!

As always, think of your audience. If the specs are simple and for your eyes only, they can be created on anything. If you're involved in a competitive bid process, you'll probably want to do it as I do.

What ever you do - don't do nothing!!