A content designer looks at each content request coming in on a particular day (this happens on a rota system).
For any specific content request they receive, they can:
- send it through to be scheduled for a detailed review and, if appropriate, action by a content designer - in which case it joins the icebox
- ask for more clarification from the requester before making a decision
- reject the request - eg if there’s no user need, it’s an editorial request or they feel the need has already been met with existing GOV.UK content
- send it through for immediate action - eg if it’s a broken link or there is something important that is factually incorrect on the live site and it needs to be fixed immediately
Items in the icebox eventually make it into a sprint backlog.
Once a content request has made it into the backlog for a sprint, it’s picked up by a content designer. They:
- review the request
- ask for clarification where necessary
- decide on a course of action (or no action)
- create or modify the relevant content item(s)
- send it for internal review
Internal review
A senior content designer reviews the piece. Within the team we call this ‘2i’ (which is short for ‘second pair of eyes’). This involves:
- looking at the original request
- considering the way the request has been handled, how this meets the user need that this content item is designed to meet, and how it relates to other content on GOV.UK
- checking that the new content is correct in its use of GOV.UK style and tone
The reviewer will then decide that this item is ready, or ask for amends. If amends are required, the item goes back to the content designer who did the work, and then goes through this process again.
If the item is ready, it either gets published, or goes out to the relevant department(s) for fact check.
Fact check
Our agreed contact at the department receives an email with a preview link. They then send this to the relevant subject matter expert.
Generally, the department has 5 days to make any comments on the factual accuracy of the proposed content. If the department needs more time than this for some reason, they ask. If we don’t have 5 days because of a publishing deadline, we work together to get the item back from fact check in less than 5 days.
When the item is returned to GDS, it is either:
- published - if there are no comments or no actions arising from the comments
- placed in the ‘ready’ area of our publishing system to be published on the appropriate date
- placed in the ‘amends needed’ area of our publishing system - if there are actions required resulting from the fact check process.
From ‘amends needed’, the item is worked on and sent through the internal review process detailed above.
Publishing
Once an item is published, the person who published it updates the relevant Zendesk ticket to let the requester, the content designer, and any other relevant party know that the updated item has been published. It can take up to 30 minutes for the item to show on the live site.
