Oct 06, 2022
Create/Change and our partners Equal Experts have been working with the Ministry of Justice and HM Probation Service to improve the effectiveness and efficiency of Recall decisions. Probation Officers must make tough decisions about returning (or ‘recalling’) people to prison. The goal of the new service is to assist the probation team in acquiring all of the essential information in one system, resulting in better decision-making.
Government services are often changed and improved over time by people and teams that come and go while the service is developed. Questions like “why is it done like this?” or “how did we come to that conclusion?” can become difficult to answer.
Our MoJ team are currently in Private beta, so they are testing the service with Probation Officers and getting regular feedback. Since they started Private beta, they’ve been documenting all their decisions through a Recall Design History.
For those who may not be familiar with the concept, a design history is like a blog. In each post, all the evidence gathered by the team and the decisions they made will be documented there. It contains anything that may be useful to return to later.
Interaction Designer Paul O’Neill and Content Designer Beck Thomson explained to me why and how they started to build it.
According to Paul, “The design history came from a need I had for sharing what I was doing as a designer with my team.”
“Agile fosters communication and openness between teams. With open collaboration, you uncover dependencies and unlock cross-pollination between disciplines and teams. Design Histories are a tool to increase this. They’re also of benefit to introverts and those who want to digest information outside of workshops and meetings.”
“It’s also a really good way to share project insights and the evolution of the solution to stakeholders. They wouldn’t understand how we work otherwise.”, Paul says.
When I asked Paul and Beck if they ever found themselves in a situation where it was difficult for the team to continue documenting the design story, they told me that the main problem for them was time.
According to Beck “Something we’ve learnt quickly is that it’s hard to find the time to do this when you’re working at pace. So it gets de-prioritised. Then when we went back to write design history posts we had to rack our brains a little bit to remember what we’d done, our thinking processes etc. In future, I think it would be better to open up a shared document and just add notes as we go along – for all disciplines to contribute and then a content designer to ‘write up’ at the end, before publishing.”
They both told me that the best thing to do to avoid reaching that point is to try to be as consistent as possible in documenting everything that has progressed. It doesn’t matter if it is a small document with 2 paragraphs or a draft with doodles. The key is always to write down those changes that have been decided to make, information that has been shared among the team… everything that may be important.
Maintaining a design history is a big – but important – commitment for the team. As Paul Hayes says in his blog post “Keeping a ‘design history’ makes it easy to explain why a service is the way it is.”
- It helps to keep the information well organised and accessible,
- A good way to share project insights and the evolution of the solution to stakeholders.
- Using a blog format makes it easy to use, which makes it easy for the whole team to participate and include all the information and not make it feel like a heavy and impossible task.
- It fosters cross-team communication, uncovers dependencies and unlocks cross-pollination across disciplines and teams.
If you want to keep up to date with original insights & digital government inspiration sign up for our newsletter.