Making the most of design histories

From: DfE Digital and Technology
Published: Fri Dec 13 2024


At the Department for Education (DfE), all designers working on service teams are required to work 'in the open'. One way we do this is by sharing our design thinking through design histories.

Design history posts are blogs that record the development of services and help us communicate:

  • user needs, stories and insights that have prompted changes
  • the key design changes
  • how we tested or plan to test our designs

Posts tell the story of how designs have been developed and how this will improve the user experience.

Why we write design histories

Working in the open in this way helps our team to apply the service standard and:

  • keep everyone informed and gain wider input
  • assist new team members in understanding the project and its history
  • share our learnings with other teams, saving time and effort

How we changed our approach design histories

On the service team I work on, we used to only start thinking about our design history post once the design work had been done. We noticed that this was leading us to miss out some of the detail about why changes had been made.

For example, we recently had to go back and add more detail about user needs to a post on displaying metrics. This was because the previous version simply stated the need without any detail about the 'why'.

This led me to thinking about sharing some of the things we do to try and get the most out of our design histories.

How to write a design history

Here are some of my top tips for writing design history posts.

Make it part of the design workflow

We find it works best if we capture the details that make up our design histories as we go. We do this as part of our regular playbacks and team discussions, where we try to identify:

  • when a design history post is needed
  • what should be included in it
  • who will work on it

It is also important to make sure you collaborate when writing the post, by asking for contributions from other members of your team. This can include designers, researchers, product managers, developers or policy colleagues. This ensures that the post reflects at least 2 perspectives on the design problem.

Include details about user needs and research

To ensure our design histories cover all of our design thinking, we make sure to include details about the research that drove the design.

We cover:

  • how strong the insight was (for example was it a recurring theme or a specific finding)
  • key findings that led to the change

To help with this, I make sure to get input from our user researchers or whoever gathered the insight.

Explain each step of the design decision

You should write posts in a way that clearly lays out all the main points of your design thinking. Things I consider when drafting include:

  • user needs - explain the user needs, stories and any insight that prompted the work
  • design decisions - describe why key decisions were made
  • the approach taken - detail the approach taken and alternatives that were considered
  • details of testing - summarise the results of any testing
  • next steps - outline planned future work or iterations

Anyone reading the post should be able to follow how you arrived at your decision, regardless of any prior knowledge of the service.

Structure posts clearly

You should make sure your design history posts are clear and well-structured.

Firstly, by following the GOV.UK content guidelines, including:

  • using headings and subheadings to organise content and make it easy to navigate
  • using plain English, short sentences (25 words or less) and short paragraphs (2 or 3 sentences)
  • ensuring all content meets accessibility standards (content designers will be able to help with this)

Secondly, by including useful examples in the right way. For example, by:

  • including design system links to any components and patterns used from the GOV.UK or DfE design systems
  • linking to prototypes (only if it that clearly states 'prototype' in the banner)
  • avoiding images and screenshots to help with accessibility and if you do include them making sure to use alt text and captions

Getting the post reviewed and approved

Once drafted I get the post checked by another content designer and properly proofread ("2i'd") before being published.

My advice would be if you are new to creating design histories, it is also worth getting your first few posts approved by a senior team member before publishing.

Discussion and improvement

Within the design profession at DfE we are always keen to keep discussing and improving the way we capture and communicate design thinking.

We have a specific Slack channel for design histories where we discuss, share and ask for feedback on posts. We also have weekly design meetings where we can share our work and gain insight on how to best talk about it.

If you are interested in discussing our use of design histories, you can contact design.ops@education.gov.uk.

If you have any thoughts or additional suggestions about getting the most from design histories, I'd welcome your comments on this post.

Company: DfE Digital and Technology

Visit website »