Your specification is a thorough description of what your website or web-based software needs to do. It should be the most reliable source of clarity for your developer. As well as defining what needs to be achieved, it serves as a contract between you and your developer, and should be created with the same attention to detail as one.
Why you need to properly define scope
I have had clients who have just started projects without a fully defined scope, and those projects have been very successful, however that is certainly not the norm. Those clients accepted going into the project that it would end up more expensive and less efficient than it could have been with proper planning. They also knew that if they spent as much time writing up a complete specification as they needed to, they would not start the project until way after it needed to start paying its own way.
I have also had clients who gave extremely detailed specifications. Everything, down to the space, in pixels, between the header title and the first paragraph.
I have to say that, that project went more smoothly than others, however most people simply do not know all their needs on entering a web project, and so fall somewhere in between these two extremes of preparedness.
The planning phase of the project is as useful to you as it is to the developer. As you add more and more detail to your plan, you understand your needs better. Items that you probably wouldn’t have thought about in a two hour initial briefing with a developer, will rise to the surface and enter your plan at its first definition.
The more of your project that you can get into your initial plan, the more efficient and cost effective your project will end up being.
In every project, whether building a house or a website, there exists the possibility that the customer changes their mind or wants to add extra features. For the most part, this is not a problem, however there are two things to consider:
- There are cost implications, and with money comes misunderstanding. However if an original specification is thorough and agreed to, that misunderstanding can be minimized.
- There are efficiency implications. When you ask to move a wall by a metre on your building project, often this move will affect the room on the other side of that wall, or the stability of the structure as a whole. These knock-on effects are also present in web projects. If your developer had known that you wanted a certain feature, he could have designed his database slightly differently, or coded his solution to make that feature integrate better with the rest of the software.
Scope creep happens on every project. In some it is massive, in others small, but if scope is always well defined, the consequences of that scope creep need not cause problems.
Building your specification
Two of the best ways to plan out a web project are with wireframes and database designs.
There are a multitude of apps and products that you can use to create wireframes of your website. Here are two free options that I found in 10 minutes of Googling:
There is also Google Drive Drawings, and one of my favorites: Apple’s Keynote, which is very similar to Microsoft PowerPoint.
You do not need any design skill, you are simply putting together elements. So these two wireframes below, done in wireframe.cc and PowerPoint respectively, work just as well as each other but for the colour information:
Wireframes are very useful for clarity. With an image, there is little chance that something will be misunderstood. You can demonstrate workflows or just show what elements need to exist on a static page. One should never rely on wireframes alone of course, as there is certainly more information to get across to your developer such as font choices, colours, and of course detailed content.
Database designing may sound a bit advanced for an average non-technical person, however it can be a very powerful way of getting information across. Bear in mind that we are not necessarily talking about a fully optimized relational database model here. We are talking more about creating a visual representation of how the raw data entities connect and interact with each other. For example a phone entity, which holds a number and a phone type (mobile, home, work), will be used and connected to entities like “company” and “person”. The idea is to break everything into entities and then create links between them. The design below was created in PowerPoint, but I could have just as easily done it in Keynote or a free package such as Libre Office.
In this database design, the entity PHONE can belong to two entities: PERSON and COMPANY, and the entity PERSON can belong to a COMPANY. This is simple concept modeling, and there are no rules about the use of arrows or lines or anything. As long as you display your thinking, you can make up your own rules.
Of course the most common form of specification is a text description. It is the one most used simply because people underestimate their own ability to create a visual representation of their ideas. Fact is, in my opinion, we are all much better at drawing a simple picture than we are at describing what we mean. As I’ve hinted above, you can’t rely on these pictures alone. Some text must accompany the images, however, a text-only brief is much more likely to cause misunderstanding.
The longer you spend planning and defining your web project, the quicker and cheaper it will be to build. Speaking from experience, the closest to a foolproof method of creating a specification is to include all three of these methods in one document.