Most web projects begin by somebody writing a specification. This lays down the functionality required and allows for the creation of timelines, budget and scope. Sounds good in principle, but in practice specifications suck.
The problem with a specification is that they become set in stone at the very outset of the project. They are inflexible and often ill formed.
Why specifications suck
For a start they are often presented to the development team (either an external agency or in-house web team) as a rigid set of requirements to be delivered. There is rarely a discussion about whether the specification could be improved. This is a waste of the extensive knowledge and talent that the development team brings to the table.
Even more significantly these specifications are only a best guess at what we believe users want. At the outset of a project we simply do not know enough about our target audience to be sure what they need.
Forming a hypothesis
Instead of writing specifications we need to start forming hypothesises. We should outline what we believe the functionality should be but accept that this will change through the lifecycle of the project.
This hypothesis should be discussed and refined in collaboration with the development team and then tested with real users. Sketches, concepts, wireframes and prototypes should all be produced, tested and reviewed. The results should refine our hypothesis to the point we feel confident to build an alpha and then a beta site.
Testing real users on real sites
Real users should be encouraged to use these alpha and beta sites and their behaviour monitored. This will provide still more evidence that helps us refine our hypothesis into a final site.
All of this might sound like a lot of work but it doesn’t need to be. Testing with real users is not difficult, time consuming or expensive. Furthermore doing away with detailed specifications actually means you can start development faster and end up with a much more lean final result. That is because time and money is not wasted building functionality nobody wants.
So before you start writing the specification for your next project, make sure you think of it as a hypothesis that needs testing, rather than a final set of requirements.
“Young Man Burning File Folder” image courtesy of Bigstock.com