Website Specification Document
17th August 2020
SO, YOU'RE PLANNING A NEW WEBSITE.
WHAT IS A WEBSITE SPECIFICATION?
WEBSITE SPECIFICATION CONTENT
What should be included in a website specification?
Table of contents
- About your organisation – A brief company background and history.
- What problem are you trying to solve? – Why is the project needed?
- High-level project scope – Is it a redesign of a few pages, a complete website overhaul, or a brand new website?
- Target market – An overview of who this website is targeted at. This could also be it’s own section in the document.
A list of the decision makers involved in the project. It is useful to include job titles/project roles, and email addresses.
The project lead should both be highlighted here.
- Rachel Adams – CEO – email@example.com
- John Smith – Marketing Manager – firstname.lastname@example.org
- Sarah Jones – Web Content Manager – email@example.com – Project Lead
Briefly describe the goals of the project. This will give developers an idea of what you are trying to achieve, which will enable them to suggest the most appropriate solutions.
- Monthly sales enquiries up by 10% within 3 months
- Decrease bounce rate by 10% by 1st July
- Increase newsletter signups by 23% by December
- 1k new Twitter followers within a year
If this project is part of a bigger project, or there will be further phases following this project, it is useful to list these to give an indication of where this project fits into the bigger picture.
- Phase 1 – Basic marketing website – Current project
- Phase 2 – Add e-commerce
- Phase 3 – CRM integration
Summary of content, by page:
The following sections give a brief overview of the type of content that will be contained within each static page. The shop is not included here and will be referenced separately.
- HOME (Insert detail when agreed with client)
- ABOUT US (Insert detail when agreed with client)
- CONTENT (Insert detail when agreed with client)
- NEWS (Insert detail when agreed with client)
- FAQs (Insert detail when agreed with client)
- YOUR ACCOUNT (Insert detail when agreed with client)
- CONTACT US (Insert detail when agreed with client)
- FOOTER (Insert detail when agreed with client)
Content type data
For each content type, the data associated with that content type should be listed. For example, if there was a ‘Person’ content type they might require the following data:
- First name
- Last name
- Email address
- Phone number
A taxonomy is a scheme of classification for your website content. You can set site-wide taxonomies to be used across all content types, or you can have taxonomies that are specific to certain content types.
For example, if you had a recipe website you might want a taxonomy of ‘meals’ where the taxonomy terms would be ‘breakfast’, ‘lunch’, ‘dinner’, ‘snacks’, ‘dessert’, etc. You could also have a taxonomy of ‘cuisine’, with terms such as ‘indian’, ‘british’, ‘french’, etc.
On a blog, the most common two taxonomies are ‘Categories’ and ‘Tags’.
There are two main types of taxonomy:
- Hierarchical – e.g. ‘Categories’
- Non-hierarchical – e.g. ‘Tags’
Another example might be an ‘Industry’ taxonomy, which you could assign to your ‘Blog’, ‘Client’, ‘Case study’, and ‘Service’ content types.
A page template is a specific layout of information. For example, your ‘Home’ page will probably look different to your ‘Contact’ page.
Some examples of common page templates are below:
- Blog post
- ‘Our team’
- News archive – lists all the sites news posts in reverse chronological order
- Contact – may have a map and a form
If you have designs (wireframes or mockups) for these page templates please include them here.
The content of this section will depend on whether a design already exists, or whether creating a design is part of the scope of work.
Design exists already
If design work has already been completed, then it can be referenced here.
There are many ways to provide design assets, for example:
- PDFs (annotated if possible)
- Invision project links
- Flat image files
- PSD files
- Sketch files
It is important to provide a style guide and/or annotations for information such as:
- typography rules
- hover states
- grid systems
Today’s websites are viewed on a wide range of devices and screen sizes. It is important to consider how your site will look, especially on small screens such as smartphones.
Mobile designs (and possibly tablet sizes) should be provided along with the usual desktop designs.
Design as part of the project scope
If the visual design is part of the project you will need to give guidance on the constraints and desired stylistic direction.
For example, if your organisation has brand guidelines that should be adhered to, they should be included here.
Each designer will have their own process, but it can help to provide:
- Brand guidelines – such as colours, fonts, logos, other graphic
- Print material – brochures, business cards, etc.
- Analysis of competition – what you like and don’t like about their websites
- Examples, and reasons for, websites that you like and dislike
Functionality is how your site actually works. This could be anything about specific parts of the website that need additional explanation.
For example, if you have a signup page, what fields are required? What happens to an entry on a contact form?
Many sites require integrations with third-party APIs. If this is the case then these integrations should be outlined here in terms of how they will work and any additional information that is needed. A good example of an integration is showing a feed of latest Tweets on your site.
Here are some examples of functionality you may want to mention, depending on your project.
- e-Commerce functionality such as payment gateways
- SSL – is this required and how it should be implemented
- Multi-lingual capabilities
- User roles and capabilities – more than 1 type of user role where users can have different permission etc.
- Analytics and tracking
- Specific functionality around search
- Performance requirements
Web accessibility is the practice of building websites that work for anyone, regardless of technology, location, or ability.
There are standards called the “Web Content Accessibility Guidelines” (WCAG) that have been developed to assist web developers in building more accessible websites.
All websites should strive to achieve the highest levels of accessibility, but if you have specific requirements around this, then outline these as part of your specification.
BROWSER AND DEVICE SUPPORT
If you have browser and device data from analytics on a current site, it is useful to include it here. As you can see from the image above, internet explorer has a small (2.42%) usage, which might drive decisions on the level of support for that browser.
At the end of 2018 and the start of 2019, the global browser landscape looks like this:
This section should outline the hosting requirements of the site.
If you already have a host that you would like to use, give details of the platform here.
ONGOING SUPPORT AND MAINTENANCE
Websites need to be updated, maintained and improved over time. If you are using a platform such as WordPress, the code base will quickly deteriorate if not regularly updated. This can lead to performance, compatibility, and security issues.
One of the most common problems that projects run into is that parties have made assumptions about who is responsible for certain tasks.
The classic example is who adds the content. Often people commissioning websites (rightly) assume that the web company will add all of the content. However, often this is not the case and the client receives an ’empty’ version of their website.
Your website specification document should include everything that is needed for this project to be completed successfully.
Some common assumptions to think about include:
- Content addition
- Design and layout customisation options
- Migrating the site to the live server
- Ongoing maintenance
Many projects, especially if using a ‘fixed-cost’ approach, will have set milestones along the way. These are clear phases of the project where you will be working on different aspects of the site.
Often, adding timescales or deadlines is a good idea, as this can help keep the project development focused and on track.
An example of some typical web project milestones are:
- Development (Front and Back-end)
- Testing and feedback
- Go Live
Even if you don’t have set milestones, it’s still important to have an idea of the timescales involved, especially if there is a fixed deadline – an event, for example.
Add any known deadlines to the specification document.
The budget required for the project should be clearly stated in this section. Often, a breakdown of the budget can be given here for the different milestones or phases, if this is appropriate.
TALK: A GUIDE ON HOW TO WRITE A WEB SPECIFICATION DOCUMENT
This was a talk that I gave at the WordPress Glasgow meetup in March of 2019.
A detailed website specification can be the difference between success and failure for a web project. It will help communicate your business goals and requirements to any internal or external teams involved in the project.
It is always worth making the initial investment to get this right at the start as it will save pain further down the line.
Good luck with your web project!
Download the web specification template
Save yourself some time and hassle by downloading the web specification template.
The download includes .docx (e.g. Microsoft Word), .odt (OpenDocument Format) and .rtf (Rich Text Format) versions.
🙌 Pay what you want pricing.
🤝 100% money-back guarantee.
Need help writing a specification?
Are you starting a web project in 2019?
We offer a ‘Discovery session’ where we work with you to produce a technical specification for your project.
Do you own a WordPress website?
Join us – and other WordPress website owners, managers and editors – on our newsletter.
You’ll receive fresh tips, recent news and top advice on how to turn your WordPress website into an efficient marketing machine.