How to write a specification

// January 18th, 2010 // Design, Development

A lot of my time as a developer is spent trying to understand what it is that people want from me. Understanding comes from duplicating the viewpoint and idea the other person has. So for me to understand means that the other person needs to understand what it is they want. So first of all you need a clear idea of what it is you want to achieve. If you do not have a clear idea of what it is you want then you will not be able to communicate it. By all means ask a technical person, who is good at explaining things, for advice if you are uncertain about anything technical. In fact, it is best if you have a technical person during the discussions and planning of any digital marketing. I have lost track of how many times a spec has come through with plans for wild and wonderful functionality, which cannot be delivered due to timescales, budget, or technology limitations.

Personally, I really don’t like to think. Thinking is a chore for me. It is different when I am problem solving, but that comes after understanding the problem domain. So before that, I like things to be explained to me as if I am eight years old (movie quote from “Philidelphia”, the Tom Hanks film). When writing a spec there may be the urge to sound overly intelligent. Remember, we already know that you are intelligent – otherwise you wouldn’t be doing the job you are doing. So well done.

The guy who took my first programming course always used to say that the first rule of programming is “never assume anything.” That is good advice. If you think that something might be “obvious”, still put it down. This applies to any resources such as links to documents, client assets, servers, and also any specific instructions. These should all be noted down and also make sure access and permission to these resources have been set up.

A spec should actually be a description of the finished product, and all information to realise the finished product.

Importances can be an issue. The functionality of a development is a priority for the developer. For a project managers point of view it may be the copy. Make sure that it is understood what the most important aspects of the system are. This again would come about during the planning if a tech person is part of the planning and design stage.


  • The project has been planned well and is feasable
  • A clear understanding of the project
  • Plain english is as little words as possible, most important points highlighted
  • List in order or emphasize importances
  • Assets and asset locations listed and permissions set up

Leave a Reply