Most agencies don’t like specifications. They’re cumbersome, they’re not very visual and they take too long to write. What’s more, most digital producers, project managers and developers haven’t really had any experience in writing them. If the agency doesn’t have a Technical Director, this can be even more of a challenge.
Nevertheless, a lot of brands have internal processes which demand specifications are written and submitted. Often a project won’t be able to progress brand-side without a specification. That’s not such a bad idea, as specifications help everyone think through the project before too many resources have been committed.
I have written my fair share of specifications for agencies and continue to do so, and I hope by sharing some of my biggest learnings I can help you.
There are some good how-to guides about writing a specification, which I’ll link to at the bottom of this article. I won’t repeat what they have to say, but here are a few important things I have learned to take into consideration before you get started:
1) Level of detail
A specification needs to be just detailed enough. Where is the line drawn? It’s difficult to say, as it really depends on the audience. Get the spec level too low and you’ll end up with something that raises more questions than it answers. Too detailed and… well here’s a story about that:
“One of our agency clients, giddy from landing a global financial brand to their client list, set off to help them develop a web-based application which would add value to one of their financial products. A great idea. The agency got their crack UX team on the project and before long a 20 page annotated wireframe was signed off. Everyone was happy and the project began. A short while later, the main point of contact at the brand moved to a different position and the brand appointed a Business Analyst from their IT Group to take over the requirements of the project. Within weeks the simple annotate wireframe had morphed into a 100+ page functional specification. Within months, it was up to 200+ pages. The functional specification was beautiful: a work of art, describing what the annotated wireframes had before, but in a lot more detail. It had a full traceability matrix, appendixes, cross-referenced requirements. So much detail, in fact, that the project budget was blown out the water. But how? The two documents described the same thing. But they described the same thing at two vastly different levels of detail. More detail is not always good.”
2) Audience
Specify the audience and make them do some work before they read the specification. Something like:
The audience for this document must be familiar with {list of documents} and with the {existing system, etc}.
3) Clear keywords
The best practice way to identify requirements in the spec should be to use the standard words MUST, SHOULD, MAY as defined in the somewhat wordy but useful “Key words for use in RFCs to Indicate Requirement Levels” in RFC 2119.
4) Clarity and brevity
Don’t make it too wordy. Lean on the designs if you have them and the wireframes if you don’t. If you don’t have designs (flats) or wireframes – and this system has a visual interface – get them before you start. There is nothing worse than the specification grossly out of sync with the wires/flats.
5) NFRs
Non-Functional Requirements (NFRs) are better referred to as Systemic Requirements because they capture the requirements of the system rather than it’s users but NFR is the most used term.
Almost every agency, if they have already written a specification, pays little attention to this area. NFRs define how the system (site/app) deals with interaction outside of what we all think of as functionality. For example, must the system cope with 1,000 concurrent users? How quick should the homepage load? How far back should backups go? All these items are good to ask, but again be careful – every additional requirement requires more budget than just the development and project management time. But not asking these questions can place the project outcome in jeopardy. Remember to ask for the traffic plan from the client, and if one isn’t available make some educated guesses from previous similar campaigns.
6) Walk-through
Every specification needs to be walked through by the key people on the project. It’s not enough to simply send it round for review. Get the key people in a room, and go through it page by page. Get these scheduled into the timing plan.
So if you find yourself producing a specification, remember the above: especially the level of detail. In the agency world you need to move fast, and delivering an overly complex specification won’t help you; but getting the balance right is a very hard task and needs your full attention. Remember that without a specification your project will probably cost more in reworking than without.
If you want to find out more about writing specifications, here are a couple of good places to look at:
1. http://www.joelonsoftware.com/articles/fog0000000035.html
2. http://www.its-all-design.com/what-actually-goes-in-a-functional-specification/
About Cohaesus
Cohaesus is the technical partner of choice to some of the worlds leading creative, advertising, marketing, communication and digital agencies. Based in London, we advise, architect, plan, build, integrate and maintain some of the best digital campaigns, applications and sites.
Extra Skills – Extra Thinking – Extra Capacity – Extra Resources
Author: Richard Bundock.
