Collaborating with Web Services to deliver content projects
Updated on 23 April 2022
This guide helps you understand how Web Services engage and work with teams across the University to deliver web content projects
At the start of each project we will ask you to identify individuals who will take on the roles of project lead and project owner.
The project owner is usually someone in a senior role in a School or Professional Services who defines the scope of the project. They have the authority to make decisions about key aspects of the project such as signing off the project plan or agreeing to the key milestones. The project owner should also be able to identify subject matter experts in their area who we can consult on specific areas of activity.
We also ask you to identify a project lead. In the case of Schools related projects, this is usually the School Marketing Officer. This person acts as the day to day point of contact for Web Services as the project progresses. Typically, they will be assigned tasks around writing and sourcing content and ensuring subject matter experts provide input if required.
For small projects it might be practical for the project owner and project lead to be the same individual.
A team from Web Services will be assigned to the project to help you plan the structure of the site, write content, and build pages in the University content management system (Drupal).
When working with Web Services you should become familiar with the University Brand guidelines with particular reference to the content style guide. This outlines our principles for creating user focused, accessible content. Any content produced during the project should meet these standards.
Our approach has been influenced by the work of organisations such gov.uk which have used content design to deliver accessible and easy to use web services. We encourage you find out more about content design below.
We will also help you understand our approach to digital more broadly and give you an insight into the major milestones of the University Web Project and the services we have launched to date. A lot of this information can also be found on the Web Services Blog.
We use a number of software tools to ensure your project runs smoothly.
We will create a Team for your project which will be used to store project documentation such as site plans and analytics reports.
Teams (rather than email) is also used for general communication relating to the project. When messaging the project team you should do so in the ‘Posts’ area of Teams. This helps communication remain clear and transparent and also makes it easier for other members of the team to pick tasks up if someone is unavailable.
GatherContent is a collaborative content creation tool that helps teams work together to plan and write content. We’ll set you up with an account should we decide to use this during the project.
We use a Microsoft Planner board to document all the project tasks associated with content creation and site build.
A typical project for delivering web content can be divided into the following phases:
Before we start working with you, we need to understand your requirements. We use this part of the project to:
Identify business requirements
The project kick-off meeting will bring the team together and discuss roles and responsibilities. We’ll get an insight into your business requirements and objectives, ask you to identify and prioritise different audience groups and explain the intended impact that content needs to have on the audience.
Understand user needs
To create useful and purposeful content it’s essential that we understand the motivations of the people using it. Working with you, we’ll identify current or intended users and get an insight into their needs.
The starting point for this is normally a user story where we define the audience need for the content. We will then try to validate these stories with real users. An example of this would be:
As a…prospective student
I want…to find out how expensive it is to live in Dundee
So I…can budget appropriately
A user story serves as reminder of the purpose of the content when we write it and a way to measure its effectiveness once published.
If the project involves replacing an existing website, we will carry out a content audit (documented in spreadsheet) and then reach agreement with you on what items are to be migrated. We generally advise against migrating the entirety of a website without understanding the value and performance of each item of content. This process should be informed by metrics from analytics and an understanding of user needs and business requirements.
Outputs of discovery phase
- business requirements
- user stories
- user feedback
- analytics reports
- content audit
- site structure
- content requirements
- project timescales
The outputs of the discovery phase of the project will be shared in Teams. These help us reach agreement with you on what the project will deliver and how long it will take to develop. These requirements and associated timescales for delivery should be approved by the project owner.
The Web Services team will document all tasks in the project Planner board. These tasks will help us visualise the structure of the website and any associated content creation tasks. It is your responsibility to check the board regularly and also ensure any tasks assigned to you are completed.
Example of web project Planner board
We’ll ask you to attend fortnightly progress meetings where we can review the board and overall progress.
Outputs of planning phase
- Populated Planner board
- Meetings notes with actions
We adopt a collaborative approach to content production. This means everyone involved in writing content should be open and receptive to constructive feedback and support team members as the project progresses.
When working collaboratively on content, a workflow will be defined in GatherContent that helps us move content through different stages of production (see example below). Everyone in the project team is responsible for progressing their parts of the workflow and responding to feedback in GatherContent when required.
Where possible, we will also test content with users and then use this feedback to refine and improve it.
Example of GatherContent workflow
There are times when we will work with shared Word documents. These should be added to Teams to allow the team to work from a single document.
The project lead is responsible for approving each item of content or web page as it’s finalised and should keep the project owner informed of any major project milestones. They must be satisfied that it meets any defined user needs, business requirement and complies with the University content style guide. Approval of content items or web pages should be communicated via a workflow completion in GatherContent or through a message in Teams.
Outputs of production phase
- GatherContent items
- Word documents
- Meetings notes with actions
- Approval of completed content items
- Web pages
The project lead is responsible for monitoring overall project progress, providing updates to the project owner, and ensuring it is delivered within agreed timescales. If a delay is expected, then this should be communicated to the project owner and a new project launch date agreed.
Prior to the launch of any web pages we will create redirects for high traffic pages. These redirects will be shared in a spreadsheet in Teams. This ensures users are directed to an equivalent new page and there is no loss of traffic or impact on search engine rankings. The project owner should confirm that the list of redirects supplied is correct and captures all content that needs to be redirected.
The project owner has responsibility for approving the project launch (this can be confirmed by a message in Teams). Launch usually involves web pages on our production server (prod.dundee.ac.uk) going live on the public facing University website (dundee.ac.uk). Once approval for launch has been given, no further content will be migrated from old sites. The project owner is responsible for ensuring that all content required has been migrated.
We will inform the project owner and project lead when the project is launched, perform a final post-live check to ensure everything is working as expected, and confirm that redirects are working.
The Web Services project team will deal with any content amendments for two weeks after launch. After this period any issues should be sent to email@example.com
Outputs of delivery phase
- Sign off/approval of project launch in Teams
- Live web pages
- Documented redirects in spreadsheet
- Completion of any post-launch content updates
- Archive of any old web pages