How we plan, write and manage our content
The Design System is made up of many different types of content, as well as comms to keep our users informed.
Work to create and maintain this content is led and managed by a senior content designer and a technical writer on the team, which depends on input from everyone on the team.
This page gives an outline around some of the most common types of content we work on in the Design System, what content folks look out for and provide a guide for team members.
The goal is to help team members improve their own content skills and get more involved in the content publishing process.
Types of content we work on
Routine comms with our community
These are comms the team have done before more than once, so we have previous experience to start new pieces of work.
Work on this content starts because the team has decided to release something or ask our community to do something.
Examples:
- release comms
- surveys (such as UX Survey 2025)
- event comms (such as Design System Day 2024)
Keep in mind
Comms are usually written in a Google Doc.
Usually, a main message is drafted first, then different versions are written for other channels.
Possible risks:
- missing or unclear information, confusing users
- inconstancy with our guidance or across channels, affecting user trust
- issues with tone and voice, harming our reputation
- anything else that can lower open, click and ‘conversion’ rates
To help avoid these risks, everyone can:
- have a look at previous drafts
- consider exploring how well previous messages worked last time (such as Google Analytics, Mailchimp, use feedback) – ensure work is peer-reviewed before publishing
When writing comms:
- follow the GOV.UK Style Guide and Writing for GOV.UK guidance
- generally, focus on telling users what they need to know, and what the need to do
- feel free to take a friendlier tone, there’s more space to be conversational compared to say, component guidance
- think about what channels you’d like to publish on, so the team can get them ready
Things team members can do
- organise related work on GitHub so it’s easy for the team find and write from
- get ready any pages we’ll link to
- write a first draft on content, you can use previous content as a starting point
- think about channels we can use and whether any follow-up messages are needed
Things a content designer or technical writer can do
Content person can help:
- bring in previous comms as examples to guide work
- pair-write with team members to get started
- review and edit from the first draft, working to simplify messages and add more structure to them
- identify information gaps and suggest ways to fill them
Content person will need to:
- assess the whole user journey to ensure users know what to do
- decide what channels we should use
- ensure consistency of messages with Design System guidance
- review before publishing
Review and publish
Review needed will depend on how complex the message is, and the number of channels we plan to use.
Smaller pieces of comms, like a simple announcement on 1-2 channels (such as Slack), usually would only need a light review of content from amongst team members.
Large pieces of comms, such as those requiring users to do multiple things and sent out using more than 2 channels (such larger releases or ticket releases for Design System Day) will need more time to review, usually from a content person or dedicated comms person in a squad. You should allow team members at least 2 to 3 days to review.
Just before publish, bringing in one or more team members for a sense check with a fresh pair of eyes is strongly encouraged.
Content people will:
- review and finalise content to ensure accuracy, consistency, GOV.UK style
- finalise comms plan
- get channels ready
Once review is completed, content person will work with the squad closest to the work to get ready to publish.
Emails to our mailing list
Emails to our mailing list need some care, as quality and trust are more important compared to other channels, and emails cannot be edited after being sent.
If you’re working with emails on Mailchimp, see the Guide to using Mailchimp on the Design System (team access on Google Docs required).
Website guidance changes
These are edits to existing guidance in the Styles, Components or Pattern pages on our website.
We usually make these small to medium-sized edits to iterate and improve the Design System.
These could end up being larger pieces of work, but we try to break work into small, manageable chunks as part of working in agile.
Peer review between team members needed before publish, this can usually be done as part of GitHub merge process.
Examples:
Simple: Fix duplicate line in Start page pattern
Routine: Update What’s New and Roadmap sections for 5.8.0
More involved: Improve content for mentioned example in the ‘Start using a service’ pattern
Keep in mind
Small changes are usually fairly low risk, especially with some familiarity of subject matter on our website.
Straightforward guidance changes can usually be led and worked on by any team member. Here’s a few things to keep in mind, things to do and ways a content person can support.
Possible risks:
- inconsistency with similar or related guidance, creating confusion
- unclear rationale or supporting research, losing user confidence in our decision-making
- users misunderstanding or misinterpreting the guidance
- ‘scope creep’ with related but lower priority work
To help avoid these risks, everyone can:
- be aware of similar or related guidance
- carefully consider how we explain the rationale for the change
When writing:
- follow the GOV.UK Style Guide and Writing for GOV.UK guidance
- generally, focus on telling users what they need to know to use the Design System, and make decisions
- use clear, simple English as much as possible
Things team members can do
- gather any relevant rationale for the change and previous design decisions
- look for similar guidance on our website that we could use as a template
- outline key messages – what needs to be changed
- list similar or related guidance on GitHub issues, so we decide how to address them
- write a first draft of the edit
Where possible, start drafting content in a Google Doc. While some changes are straightforward, it’s good to prepare for good feedback and review.
To prepare the Google Doc, use headings and text to:
– label draft copy – show where the edit will be added (usually the page, heading and perhaps a quote of existing sentences) – quote or describe what will be replaced, or deleted
Allow tracked changes, suggestions and comments so team members can use them to give feedback and review content.
Things a content designer or technical writer can do
Content person can help:
- pair-write with team members
- develop the content after the first draft
- help decide the right level context needed to introduce difficult topics
- restructure the page and headings, if needed
Content person will need to:
- guidance content is clear and simple for everyone
- ensure consistency with existing guidance on the website
- ensure GOV.UK style and content guidelines are followed
Review and publish
Make a content person aware of this work. This can be done through team processes such as the GitHub project board and ceremonies.
Content people are happy to support wherever needed.
These edits are usually lower risk, so peer review amongst team members, as part of GitHub merge process, is often fine.
Ask a team lead or content person if it feels higher risk amongst the points in ‘Things to know’.
Future updates
This draft was shared with the team in February 2025, who gave some points for improvement on a further draft:
- adding templates to help with layout and sentence structure
- more clearer permission and remits
- clear criteria to follow to decide when to involve a content person (this might be difficult)
- practical writing resources, such as to explain active vs passive voice