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 🙂