Managing website production
Here we cover:
- considerations before producing a (new or replacement) website
- considerations about web developers
- your involvement.
You should get web development professionals to do the work. However, if you hand over control without preparation, monitoring and management, you may get an unsatisfactory result or may end up paying too much.
See also Publishing a website, which covers website hosting, domain name registration, content management systems and web editing software.
Considerations before producing a website
Work with other staff and stakeholders to get an idea of what the website is for and what content should be on it.
Document your thoughts (and expect changes along the way):
- a wishlist of content ideas, functions and design elements (these can be mixed up – it will be useful to a developer regardless)
- a webpage, roughly mapped out on paper, with the main sections and potential pages listed underneath each section.
When you have a working understanding of the content, a rough idea of the various sections and any functions (e.g. search), draw up a brief for the developers. (Download a sample brief [PDF], courtesy of the National Welfare Rights Network)
Consult widely with as many people as you can who have recently developed a website and ask about any surprises along the way. This will help you think about questions you need to ask, and assurances you need to get, from the developers.
The developers should take your ideas and present some optional designs for comment. They should comment on any irregularities regarding additional functions/features you request.
As the website is taking shape, but before it is finalised, you should do some user testing (see below).
Have some idea about:
- who will update the website regularly
- how much time they will have to do so.
Someone will also have to liaise with technical staff who will maintain the website into the future.
Considerations about web developers
During the website's development, the developers will control all aspects of the website. They should relinquish control once the website is launched. This will mainly involve providing you with usernames and passwords that allow you to access and edit or modify the website.
Before contracting a web developer, get written assurances that:
- the website can be moved and won't be hosted long-term by the developers themselves
- you won't be involved in an ongoing maintenance agreement after the website is finished
- other developers could step in and modify the website and the systems that support it, if the relationship between you and the developers went sour
- you can access the domain name registration information and can assign another party to make changes to this on your behalf.
Don't get too deeply involved in technical discussions with the developers. Instead present them with a problem or desired function and have them explain how they would address that issue. Refer to examples on existing websites.
You could run their proposed solutions by someone else with expertise but keep things at a concept level when talking to the developers or you will be taking responsibility for choices of technology that may not be the best for the job.
Give potential developers an approximate figure of how much you intend to spend (maybe with a little in reserve). This is the only way they can make sensible decisions about the scope of the website.
Your involvement in the website's development includes:
- determining and providing content
- planning and conducting user testing.
Schedule the major steps in the website's development. NB: The developers building the website is only one facet of this. Much planning needs to happen beforehand. You will also need to have 99 percent of the content ready when the website is launched.
It it is important not to disregard planning. Whatever planning you do need not be perfect. ANY effort you put into planning will have benefits.
The main steps are:
- Arrive at a rough idea of why a website is useful. Document this.
- Discuss with stakeholders what should be on the website (with reference to step 1, above. Document this.
- Determine who your main user groups are (2 to 4 groups). Document this.
- Revisit the steps above – so that the concept, content and user groups correlate.
- Draw a rough diagram of how the home page will look – main navigation links, functions (e.g. search). Don't include any graphics.
- Develop a brief and engage developers.
- Oversee the development. Engage with the developers regularly – as much as you can. There will be little time for review once the site is built.
- Sign off with the developers
- Reclaim control of the website with admin passwords for all areas of the site.
After the website is finished:
- Ongoing addition of content will be required.
- Technical maintenance will be required from time to time
- The website will need upgrading when significant new modules/functionality is added.
- Consider redeveloping the site again after 3 to 4 years.
Work out with other staff and stakeholders what content will be on the website.
You should have a strong idea about what pages and content are likely to be on the site, and how they might be organised into categories for navigation. Expect your ideas about these things to change as the website is developed, during conversations with the developers and through user testing. Look at existing websites to inform your ideas.
The way sites are made now mean that content is very separate from the technology and graphic elements of the site. This means you can start writing up the pages that will go on the site (just the content) before/while the site is built. You can do this in Word or any text editor but it may help to consult the developer on the best word editor for your site.
At various points while the website is taking shape, its a good idea to test it with typical users from the target audience. (If you cannot find such users, test it with colleagues and friends.) By conducting user testing, you will be able to ascertain if:
- the content that users need is there
- the content is where users expect to find it.
User testing does not require technical experts – any informal testing is helpful. For example:
- Provide users with the main navigational (section) headings for the website
- Present users with a a number of typical information-search scenarios or questions to answer.
- Ask users in which part of the site find the information/answer.
- Note users' behaviour/answers and feedback. Use this to inform/refine the websites’ navigational structure.
Such testing can be done on paper before the development starts ('paper prototyping') or on a 'live' prototype set up by the web developers.