A quick guide to commissioning websites.

commissioning2.png

When you commission a website, particularly if you haven't done this before, how do you make sure that you end up with something you like and which really works for you? 

The most common pitfall is that you provide the web developer with a pretty vague brief and then you leave it to them, as the ‘expert’, to interpret what this means. It may be true that you do not have the technical expertise to build a website. However, unless you have been living in a cave for the last twenty years, you will have a lot of experience using websites, and you can use this knowledge to help you put together a detailed ‘user requirements’ document which gives the developer a much clearer picture of how you want the site to look and what you want it to do. 

The user requirements document does not require any technical input from you.  It should set out, in plain English, why you want a website and what you want it to do for you / your organisation. If you search online you can find numerous templates for this, so I’m not claiming the following list is unique, but I have found it helpful both when commissioning building websites and when designing them.

User Requirements 

1 - Information about your organisation

  • What is your purpose? - is it to sell shoes, support refugees - why do you exist?
  • What is special / unique about your organisation? What distinguishes you from the other organisations operating in your sector?
  • What is your organisational culture? Are you friendly, formal, youthful, mature?

The web designer will need this information, as it will impact on the look of the site from the outset. A site for a law firm will clearly have a different appearance to that of a young people’s charity, but there are also more subtle distinctions. A new law firm with a disruptive approach will require a different look and feel to a 150 year old law firm which sells itself on its experience and gravity. 

2 - Your Audience

  • Who are the people who will be visiting your website?

Try to build up a picture of who your website is aimed at. Think of their age, gender, education, level of affluence, values, how they speak. This data will be useful both in helping the designer think about the look of the site and also when you put together the sites's content.

3 - Purpose of site

  • What do you want your audience to do when they visit your site? What action(s) do you want them to take?

Whatever the nature of your organisation you will want your audience to do something - buy your shoes, donate money, write to their MP etc. There may be more than one action you want your audience to perform and in this case, is there a sequence for these actions or does the order of these not matter? Given this information, the designer’s task is to make it clear to the audience what action you want them to perform, and to make it easy for them to do this.

4 - Look and functionality

  • What do you want the overall look of the site to be?

    The easiest way to do this is to research websites that are targeted at a similar audience to yours, and provide a list of 6 or so sites that you like / hate both in terms of their appearance and their functionality. Remember it's not what appeals to you that matters, it's what works for your audience.

5 - Site Structure

  • What content structure will make sense to someone visiting the site for the first time? What might that person want to know and how will you make it easy for them to find this out? 

Start with your audience. Why will they be visiting your website and what is it they will want to know / do? It may well be that there are different groups within your audience who will want different things. Factor this into your thinking and make it as simple as possible for each of these groups to get what they want from your site.

You will know all about your organisation and what it sells, promotes, campaigns for. This means that you may not the best person to judge what content structure works for a person who is visiting your site for the first time. This is definitely an area where it is useful to do a little market research - checking out your proposed content structure with people who don't know your organisation as well as you do.

  • What is the most sensible breakdown of main categories for your website which will then appear as the main navigation bar at the top of the page? 

You probably do not want more than a maximum of six headings for this. If you have a lot of information on your site, think about the best way of organising this under your 6 (or less) headings. If you have come up with a definitive list of all the content topics you want to cover, this is where your developer should be able to help you in thinking through how best to organise this in terms of primary and secondary navigation menus.

6 - Timeline

  • When does the website need to go live - is there a specific deadline for this?

    In my experience the most common reason for website not being ready for the agreed launch date is that the person commissioning the site does not provide the agreed content on time. So - agree a schedule with the developer which included a date when they will need all the content and images from you and MAKE SURE THAT YOU DELIVER THESE ON TIME. Being realistic about how much work is involved in developing the content and allowing sufficient time to complete this will save a lot of pain at a later stage.

7 - e-commerce

  • If you are going to be selling directly through the site,  how many sales at what price you are anticipating over the first year?

    Inevitably this is a guess on your part but this will give the developer a sense of what e-commerce model will work best for you and the level of traffic you are expecting. 

8 - Sign off

  • Who has the final sign off for the finished site. Is it you or is it another manager?

    If another manager has the final say, they will need to have some involvement at the critical points in the design and build of the site, including signing off the user requirements document. Your developer will not be happy if the website is finalised, only for a senior manager to come up with a different set of requirements at the last minute. The only thing worse than this for a developer is for the final sign off to be by a committee, when everyone then has a different set of requirements. 

If you haven't commissioned a website before, using this format should give you a pretty good starting point - good luck!

David Edwards