Ah, the good ol’ specification. If there’s one thing I’ve struggled with during my years working in the web industry it has to be specs. Are they worthwhile? Does anyone actually read them? Are they a bureaucratic burden or an overlooked necessity? It seems no one can make their mind up.
I started writing specs for web projects about six years ago when the agency I worked for began developing more complex and functional sites. A year out of university and coming from a programming heavy background, it seemed like the logical thing to do – you’re building a product so naturally you should specify all functionality and interactivity in a blueprint document. Simples. Or not. The reality is that it’s not this black and white and I’ve seen projects that have benefited dramatically from specs and others that have crashed and burned as a result of them.
What’s the point?
It doesn’t matter if you’re building a small web site with only a tiny members area or the next Facebook, the theoretical point of a specification is to create a definitive document that outlines the entire functionality of the project, giving developers a schematic to work to and, perhaps even more importantly, making sure both yourself and the client are on the same page. A spec should help designers create more accurate mock-ups, developers code more efficiently, inform clients about what exactly they’re getting and keep the whole project running on time, on budget.
Oddly enough though, it doesn’t always seems to quite work out way. Don’t get me wrong, when the moons align and everyone’s drinking the same Kool-Aid, a detailed specification can make running projects a breeze. Clients know what’s in, what’s out and have a solid understanding of what the final site or app is going to look like, developers have a fantastic blueprint to reference and code to and designers don’t go off on tangents and introduce all sorts of crazy new functionality in their mocks. When specs work, they work well.
Unfortunately though, they also come with a weight of disadvantages that can make them quite unappealing to bother with.
The problems with specs
Perhaps out of all the spec naysayers out there, 37 Signals is the biggest advocate against them, condemning them as fantasies that are only used to appease stakeholders, wasting people’s time and doing nothing other than constraining us all to concepts and functionality that we have no business committing to at such an early stage. There’s a lot to agree with in what they say.
“The business world is littered with dead documents that do nothing but waste people’s time.”
There’s no denying that specs create a large burden of maintenance and I’ve worked on projects where we’ve spent weeks with the client debating what should go in the spec and how functionality should work rather than just getting on and doing it, ironically spending more time updating a document with alterations that it would’ve taken to do in code. And don’t even get me started on just how many clients (and developers) never even bother to read them. Ultimately, on some projects, they were more of a needless bureaucratic burden than anything else.
And, just like 37 Signals say, you end up building your product to spec rather than to purpose, robotically following words written on a piece of paper rather than trying to solve the problems at hand with a holistic view of what’s best for the entire product.
Specifications aren’t all negative though and, aside from the many positive features I pointed out right at the start of the article, they’re also great tools for managing time and budget, enforcing the constraints of a project and preventing scope creep which, in my mind, are perhaps some best weapons any web agency can have on their side. How often have web projects ballooned in scale because the client somehow mysteriously manages to keep sneaking in new features? How many times has that simple contact form become a fully detailed enquiry system? How many times has your simple availability calendar turned into a full blown booking system?
Perhaps these things are avoidable by improving communications with clients and learning to say no more but, ultimately, it’s a lot easier to control the scope of a project when you both have a shared, detailed vision of the product from a very early stage. Specifications are a great way to achieve this because they force you to think about everything up front and go through functionality with the client right before you even begin coding. Not only is it far easier to make large scale, sweeping changes at this stage in a project but it also means that if you’re somehow on completely the wrong page from your client, far less work has been lost.
What to do?
Deciding on whether or not to write a functional specification is a tricky question, one that I wish we knew the answer to. Sometimes they prove to be incredibly valuable, saving time and hassle further down the line, whilst other times they just end up being an albatross hanging around the neck of the project, weighing the whole thing down, constraining you from achieving the best solution.
“Forget about locked-in specs. They force you to make big, key decisions too early in the process. Bypass the spec phase and you’ll keep change cheap and stay flexible.”
There are alternatives to specs though that can work well and sometimes just rapidly prototyping work is far a more effective that trying to write down all its ins and outs first. Likewise, implementing a test driven approach and creating test case scenarios first can be very beneficial. Sometimes even just writing down a brief high level overview of the system in question rather than a full blown spec can work wonders. Perhaps though, one of the most worthwhile things you can do is utilise an agile development framework that makes altering things as quick and easy as possible, taking the sting out of a lot of the late-in-the-day changes that specifications are designed to curtail.
At the end of the day though, we don’t have a definitive answer to functional specs and just judge each project we embark on individually, trying to gauge whether or not creating one is the best idea for the job. Sometimes this involves writing detailed functional specs, sometimes just quick outlines of what’s involved and sometimes nothing at all. Until we figure out a better, completely definitive solution, it’s the best we’ve got.
What about you? Do you bother writing specs for web projects?
Image credit: The Telegraph