Skip to main content

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:

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
This page was last reviewed on 22 January 2025. It needs to be reviewed again on 22 July 2025 by the page owner #design-system-team-channel .
This page was set to be reviewed before 22 July 2025 by the page owner #design-system-team-channel. This might mean the content is out of date.