Throw out your website’s specification

Web & Digital Advice

Digital and web advice from Headscape and the addled brain of Paul Boag... tell me more

Paul Boag Posted by: Paul Boag On Monday, 24th June, 2013

Throw out your website’s specification

Stop writing a specification at the beginning of every web project. Think instead about forming a hypothesis.

Digital Strategy Short Audio Tips:
The estimated time to read this article is 3 minutes
Play

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.

Graph showing that we only really understand users after the website has been launched.

It is only after watching users interact with our site that we really understand what they want. In light of this, upfront specifications make little sense.

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

Become a web expert with our newsletter

Receive invaluable advice every three weeks and get two free video presentations for subscribing. You can unsubscribe in one click.

Blog Updates

You can follow all my posts by subscribing to my RSS feed or signing up to my email newsletter above.

Podcast Updates

Subscribe to the podcast via itunes or RSS. You can also subscribe to my quick tips via itunes and RSS too.

Social Updates

I am completely addicted to Twitter so try following me there. I also have a Facebook page which contains considerably less waffle.

Comments

Boagworld is a community, not just the voice of one blogger. You've read the post, now its time to get involved.