Specification Hell

I just spent my afternoon working on a 50-page functional specification. 

Now that I’ve been on the agency side for more than a year, I’m confident in reporting that agencies hate reading specifications almost as much as clients hate writing them. 

The world is full of dry documents, and I try (probably like most people) to avoid them as much as I can. That’s why I spend as little time as possible on Mr. Nielsen’s site or over on the W3C. What always strikes me about specifications for websites, however, is the extreme contrast between the engaging, colourful, user-centric thing which is the intended end-result and the grim, stultifying 100-page dirge which is usually provided at the beginning of a web project.

Functional specs have emerged from a kind of pastiche of needs. On the one hand you have the client who is forking out tens or hundreds of thousands of pounds. Not only do they (obviously) want to know what they’re getting for their money, but specifications are impressive, aren’t they? Nothing like an enormous great fat wad of a document to really show the agency that you mean business. From the agency side, you have a bunch of project managers and web developers: the PM’s are desperate to assign days and the web developers are desperate to avoid those “ooh, you couldn’t just…” moments later on in the project.

Under the hood is also a kind of legal wrangling which everyone hopes they won’t ever need – what if it all goes to shit, relationships break down and all those “sure, I’ll just do X” or “they said they’d do Y” moments come back to haunt you?

The net result is grim, particularly when you take a step back and consider the impact on creativity, innovation or “moving things forward”. When developers and PM’s are working to the letter of a specification, it’s no wonder that those additional extras get left behind. When your document binds you so closely to a fixed output (“the dropdown on the right displays X, which when selected does Y to div Z”) you don’t have a hope of being flexible, let alone able to take on board user needs or requirements.

In my experience, the reality is far from the dotted “i” and crossed “t” scenario which forms the backdrop to specifications. Developers are terrible (as is everyone, IMO) at estimating effort, usually resorting to doubling their initial guess because they know someone somewhere is going to take the piss later on; PM’s are terrible at taking flexibility on board; clients are terrible at writing specifications (or reading documentation). 

People are, after all, human.

What actually happens in a successful web project is very different, very fluid, and relies on a series of largely undefinable communication strands between client and agency. Personality plays a huge role in this: I’ve worked, for example, with developers who are incapable of doing anything except working 100% to the letter (me: “this dropdown has 10,000 items in it” – them: “that’s what you asked for”), and I’ve worked with clients who are 100% happy for the agency to drive the entire process, just wanting “a website” and no further questions, thanks anyway. 

There is no golden bullet, but in my experience there are a few approaches that have proven themselves time and time again.

  1. Be prepared to be flexible, both as a client and as an agency. Rigidity is almost always going to go wrong. Start the process (as client) knowing what you want but be prepared to accept different approaches. If you’re on the agency side, be creative enough to think about (and suggest) approaches that you’ve seen out on the web – say AJAXy validation or particularly good ways of going through a sign-up process. Clients usually like nice things.  
  2. Put legal measures like contracts in place but remember that the chances are you won’t end up in court and it is usually better to devote more time to talking and meeting consistently and regularly during your project than to writing huge, hefty legal horrors. Use a standard contract, attach a design brief, get everyone to sign it. Then move on.
  3. Always (always!) have a single point of contact defined early on in the process. Never step outside of the golden rule – the contact is between these two people: one from the client, one from the agency; any other communication goes through you, with no exceptions. Make sure communications are logged (usually via email, but bug trackers, Basecamp, Google Docs etc etc ultimately do the same thing). 
  4. If you’re a client with a vision or an agency with a solution, create it as visually as you possibly can. Instead of writing vast documents, create the following (in increasing order of effort and usefulness):

    – hand-drawn sketches of the site map, key pages, user interactions, “pinch points”

    – wireframes, initially in Powerpoint but ultimately in something like Axure or Protoshare. You can also use wikis or tools like Google Sites to re-create key bits of the new site

    – if you have really hefty bits of functionality which can’t be explained easily with a wireframe, consider building a working prototype. I can hear the intake of breath here – yes, it’s a hell of a lot of effort, but if you have a friendly web dev who can knock out something in a day or two that explains functionality better than a 100 page document, it will pay for itself in no time at all.

The best web projects I’ve worked on have had a core document which clearly explains the overarching reason for the redevelopment, any constraints (either technical or otherwise), and then references a sitemap and a wireframe or prototype. Somewhere in the background is usually a contract, too.

That’s it. The rest is down to clear, open communication, flexibility and – perhaps most important of all – a shared committment to make the new site better rather than just “redesign” it.

Incidentally, if you hear (or use) the phrase “content migration”, the project has probably failed already 🙂

6 thoughts on “Specification Hell”

  1. A timely post Mike as I’m about to embark on an enormous freelance project with a new client (and was feeling a little nervous).

    Thanks for speaking sense as per usual.


  2. 50 pages – Ouch! I feel your pain. The really scary thing is that this sort of stuff still seems to be happening despite this being an really old problem.

    What you’re describing sounds like what software engineers would call a “Waterfall model” which kind of assumes that if the specification is thorough enough then it will miraculously describe exactly what’s needed and that the programmers will miraculously implement every requirement to the letter.
    In theory software engineering has moved onto more hip and trendy “Agile methods” which try and keep specifications small and development iterative but the situation that Mike is describing is all too common.
    My contribution to the issue is called “Writing a creative brief for a computer exhibit“. But perhaps a better way of summing it up would be to say “A specification is not a special tool whereby anything you write will magically happen – its a method of communication to tell people what you’d like them to do”

  3. @Joe C – Yeah, it’s very much the remnants of the waterfall model that I see all the time; although agile stuff is starting to appear it is still IMO approached with a fair bit of suspicion, in and around the museum sector and elsewhere.

    There is something about “agileness” that certain IT types very definitely still equate to “not very serious” – similar to “lightweight” and “enterprise”…

  4. @Mike
    Yeah, like you say “agileness” doesn’t seem to have got as much traction as you’d expect. People find something very re-assuring about a good thick specification.
    There’s also the influence of project managers and quality assurance types with a background in Construction projects. As far as I know the Waterfall method is pretty much the only way of doing those projects so they tend to apply it to everything.

    BTW: I just realised I should have done the links in my last post as HTML (duh). Is there a way that I can edit the post or can you do it for me?

  5. This all sounds horribly, horribly familiar from my last experience of a big website relaunch.

    And like Jenny, timely for me. I will be sharing this with all involved in the project I’m about to embark on.


Leave a comment