All designers working on service teams in DfE are required to work in the open and share their design thinking through design histories.

There are posts available on the DfE digital blog and Design in government blog with more information and advice on the why and how to develop a design history for your service.

Teams can create a design history for each of the services in their area.

Set up a new team

  1. In Strapi, check if your team already exists in Content Manager > Team.
  2. If not, click ‘Create new entry’.
  3. Enter the team name in the Title field.
  4. Use a single word or hyphenated words for the Slug (for example, 'design-ops').
  5. Set Enabled to ‘True’ to make the team design history live.
  6. Provide a short overview of the team in the Description field.
  7. Select the appropriate portfolio for your team.

Set up a new service

  1. In Strapi, go to Content Manager > Service to see existing services.
  2. Click ‘Create new entry’ to add your service.
  3. Enter the service name in the Title field.
  4. Use a single word or hyphenated words for the Slug (for example, 'accessibility-manual').
  5. Set Enabled to ‘True’ to make the service design history live.
  6. Provide a short overview of the service in the Description field.
  7. Select the team the service is part of and link any existing posts.

Create a new post

  1. In Strapi, go to Content Manager > Post and click ‘Create new entry’.
  2. Add your content.
  3. Create a slug for the post, set the publication date, select the service and add relevant tags.
  4. Save and publish the post.
  5. Check how the live version looks on the design history pages and make any updates if needed.

Post titles

The limit for post titles is 70 characters. The title should be helpful to people who come to your post with no context to assess whether it will be helpful to them.

Titles should describe the problem you explored or solved, and should start with a verb unless the character limit makes this impossible. It might be helpful to consider both the style for titles in the writing for GOV.UK guide and guidance on naming your service.

Post description

The limit for post descriptions is 250 characters. The description should further help people assess if the post will be helpful. You could include the design problem you were trying to solve, or the insight you were acting on.

Include links to any components and patterns you have used from the GOV.UK Design System or DfE Design System. For example, the accessible autocomplete component (opens in new tab).

Linking to a prototype, or a specific page in a prototype, might be the easiest and most accessible way of sharing information about the page, its content and functionality. You can link to a prototype, but you’ll need to include password information in the post.

Only link to a prototype if it clearly says ‘prototype’ in the banner. Do not link to a prototype if there’s a chance someone might think it’s a live service they can use.

Make sure you apply version control to your prototypes so you can look back at previous versions.

Images

It’s tempting to include screenshots of service pages in design history posts. This means that images will include a lot of text which would create accessibility problems.

Text in images is not automatically read out to screenreader users unless there’s alt text. They can also pixelate for magnification users, who do not have access to the alt text.

Instead of including a screenshot, you can either include the text you changed when writing about what you changed or link to the specific page in a prototype.

Screenshots

If you do need to include screenshots, you should write out the text from each image in the post so that it’s accessible to magnification users and screenreader users.

It’s best to use the alt text field when you upload the screenshot to say where in the post you’ve described it and write out the full description in the body content. For example, an alt text field could say ‘screenshot described under image’.

Include information in your description about the layout of the page, like which text is the title, what has radio buttons or checkboxes and what the button says.

Any information that’s available to fully sighted users’ needs to be available as text.

Alt text

The alt text character limit is 255 in Strapi. There is guidance on how to write alt text in the service manual (opens in new tab).

Captions

Captions give images titles. They are read out by assistive technology when there is alt text present. Do not duplicate your alt text in your caption. If you use captions correctly, you can write shorter alt text.

For example:

Caption – Screenshot of the new interruption page Alt text – Screenshot described under image

You should then fully describe that image in your body text.

Content snippets

When including snippets of content in the body text of your post, introduce them with a sentence like ‘The content is’ and use the ‘inset text’ code to format the content snippet. This makes clear it is example content.

You do not need to add quotation marks to content inside the inset text div.

If any of the content in your snippet is a header, do not format it as a header. Formatting it as a header would confuse the structure and impact on accessibility.

Instead, you can format headers as bold. As it’s inside a div, you will need to use the <strong></strong> html to do this, rather than Markdown.

The code for the div for a content snippet is:

<div class="govuk-inset-text">
content...
</div>

Tags

There are currently tags relating to internal teams who own internal services in Strapi, big programmes such as schools, apprenticeships and supporting families.

There are also tags for user groups, types of service and user-centred design themes. To request a new tag contact DesignOps.

Making your design history post private

You may need to make all, or some of, your design history posts 'private'. This allows only users with a password to access them.

To make your design history private:

This removes your design history from the Services for your team’s page. The private design history will only be accessible with the URL and password.

Ask for advice

If you’re not sure whether to make your design history post private, speak with your:

  • product manager
  • service owner
  • subject-matter experts

If you need further advice on design histories, contact DesignOps.