Working in sprints means we can respond quickly to changing priorities. This is vital when working on content for government.
It also means that there’s no need for departments to send through content requests months in advance.
There are 3 things to remember when making a content request in order to make sure it’s completed when you need it, and to the standard you expect.
1. Make your request clear
The quality of a request is important. If it isn’t clear, is long and difficult to understand, or doesn’t state all the changes you require:
- we can’t estimate its size properly, so other work planned in for the sprint doesn’t get done (this leads to disappointment and frustration)
- we may miss something important that you’ve assumed we’ll know about (this leads to disappointment and frustration)
- you may not get the work completed when you need it - we may need to plan the work you haven’t mentioned in for a future sprint (this leads to disappointment and frustration)
What to include in your content request
Here’s what you need to include in order to submit a content request that GDS content designers can act upon:
1. A list of every URL affected. Anything that isn’t included in the original request will be counted as a new request and scheduled in for a future sprint.
2. An explanation of how the facts have changed, or why a new piece of content is required. Include background information, links to source material, evidence of need, and anything else that will help the content designer make a decision on your request. Don’t re-write the text thats currently live on GOV.UK. If it makes it easier for you to explain, you can make suggestions, but don’t expect that we’ll simply paste your suggestion onto the page. We always re-write content in GOV.UK style and tone according to user need.
3. Dates (where appropriate). We need to know when things need to be live and why so we can schedule the work effectively.
4. URLs of anything you want us to link to. And if an external URL (ie not on GOV.UK) isn’t live yet, tell us when it will be. Content with broken links in it shouldn’t make it through our review process to the point that it gets published, but when time is tight and the workload is heavy, this occasionally happens. You can help us by being clear when links aren’t working yet.
2. Use the relevant GOV.UK Support form
This comes into us through Zendesk and allows us to keep a log of all the work that’s been requested, all the communication relating to it, and what state it’s in.
Once the form has been submitted and you have a ticket number, use Zendesk for all communication except fact check comments - fact check has its own process and is logged separately.
3. Submit your content request at the right time
At any one time, we have a great deal of work to complete. This is generated from the various government departments and agencies, the general public, and internally. Our work is organised in order of priority, and the priority shifts from sprint to sprint based on a number of factors.
To make sure your content request is completed when you need it, as a rule of thumb it’s best to give us:
- 1 month’s notice for a quick change on a standard piece of content (a quick answer or a guide)
- 2 months’ notice where the change is more complicated, or involves a calculator or other item requiring input from a developer
We don’t always need this amount of time and will work within your timescales whenever possible. But if you can give us this amount of notice, it makes it easier for us to get the content live when you need it live.
There is no benefit in making the request more than 2 months in advance
Sometimes we get requests for changes that won’t happen for several months.
When we receive content change requests a long way in advance, they’re reviewed and placed in the icebox. They then sit in the icebox and receive no attention until it becomes time to deal with them.
In order to manage our workload, we won’t engage with the requester, have meetings or plan anything to do with the content request before it becomes necessary.
When we receive last-minute content requests we try to accommodate them. The problem is, we receive a lot of content requests, and the items we’re working on in any one sprint need to be delivered in that sprint. If we receive a last-minute content request it places an extra burden on the team - and the team are already working to capacity. This means that, even though a request is urgent, if we receive it last minute, it may have to wait until the following sprint before it gets actioned.
