Writing a specification for a website or web application can be difficult, what do you include? How much transparency should there be? What about pricing?

Here are some tips to start you on your way in a simple who, what, why, when & where format based on what I’ve learnt over the past few years.

What

I’m afraid I can’t really start with who, because without the context of what you are making for you’re client, it would be pretty confusing. So how should you go about describing what you are making?

You should start off with a quick paragraph or two on your objective i.e specify in layman’s terms what you are producing for your client. If you are making a website it may be pretty obvious what one is, but what kind of features are possible (even if you aren’t including them), however if you are making a web application, it’s probably best to explain what the difference is to website and desktop applications. Either way, what are the obvious benefits to the client?

I can get a website for £50 on the net.

We hear this a lot, but you can pre-empt this by explaining why you’re solution is more expensive, and suggesting in good-faith that you can look at more affordable, less extravagant solutions if they are looking for a cheaper presence.

Flexibility

Some projects don’t have strict deliverables, so what process will you go through to manage the scope of the project and how it’s designed? If you’re relying on prewritten systems, they might be fixed in implementation so it’s worth mentioning what you can and cannot do with them.

External Code

Are you going to be using open source systems like Wordpress or external services such as an API, and how are you going to plan for updates / changes in the specification? What happens if such service / codebase becomes unavailable or no longer supported? While these questions might be of no interest to the client, they are important to cover your back in event of any issues.

Who

This is section is very important for not just your client but yourself also, first start with explaining whether it’s a public website, private intranet, or public/private web application and how that relates to the type of visitors to the website. The questions you should be asking yourself when looking at visitors are:

• How computer literate are they?
• How patient will they be, i.e are they broadband guzzling script-kiddies who must have everything immediately or they’ll go elsewhere, or employees who don’t mind waiting 10 seconds for a large page of data to load?
• What functionality will they be using?
• What data should or shouldn’t they have access too (whichever is more appropriate)

Context

How these users access the website/webapp can radically change how you display it. With mobile browsing becoming more and more popular it may be worth developing a streamlined mobile-specific interface, but context doesn’t just what devices they’ll be using, but the situations of access, for example when printing orders, a user might just want a quick list to scan through, but when dispatching them, the warehouse staff might only need to see a single order in much greater detail.

When

If you are not particularly great at predicting when projects are going to be complete, discuss this with the client, and ask when their deadlines are – it might turn out that they don’t really need certain functionality until later down the line, so you can set a short deadline for the core functions and work from there. If you are following an agile development model, it’s also hard to determine exact dates, but you can always set deadlines with get-out clauses providing you give at least a set amount of notice.

It’s a good idea to set deadlines for your client too, an idea I came across through Paul Boag [I can’t find the exact article, sorry]. It may only be that you need sample content from a client to initially fill their website, but it keeps the relationship bi-directional, rather than the client just polling you for updates all the time.

Clients like to see their projects in action, you might be including them in your acceptance testing of each iteration, but if you aren’t planning on meeting with them to discuss the project details further, it’s worth considering booking progress meetings where you can demonstrate features to the client. This also helps with you’re project management as it helps define internal goals to be reached before these meetings. The meetings need not be set in stone, but nobody likes to repeatedly delay them so it’s always in the back of your mind.

Why

It’s always good to finish on a positive, so before providing a list of your costs which is likely to give the client a heart attack, tell them why they want this project to happen, why should they be excited, and also most importantly why use you? You may have some specialisms that will guarantee success, or a close relationship with the client which you feel you can use to both yours and your client’s advantage