A significant amount our work in DS is focused on specialist legal content. As part of the move to make justice services easy for citizens and business users to use, the content team here in DS is working alongside their colleagues elsewhere in the MOJ to transform important legal content hosted on justice websites.
GOV.UK aims to put the user first. What this means is that the content on the GOV.UK site must be user-friendly, easy to find and navigate, and of reduced volume, but without losing any of the legal necessities or nuances of the original content. This is quite a challenge.
Over the last few weeks, the content team in DS has been looking at the specialist content that is contained on the Legal Aid Agency site. Content includes legal guidelines explaining how legal aid lawyers can submit an application for their client, or a make a claim in order to get paid. These documents can often be complex and technical, and in order to put the user-need first, the team at DS must be entirely clear on what information users, most of whom are legal practitioners, want to gain from the documents, how they use them, and what is legally required of the site. Getting started in this daunting task is very difficult. Here’s what we’ve done so far…
Step 1 – getting the agency onboard
We’re running this content transition as an Agile process. No Agile process has succeeded without the presence of some key roles. Our first task then was to find three key people - a Product Owner, a Scrum Master or Delivery Manager, and a team.
The Product Owner defines the ‘what’. That is, what will be built, what the end product looks like – he or she defines the scope.
The Delivery Manager, working with the team, defines the ‘how’. How will the team achieve what the Product Owner wants?
It was crucial, given the specialist content of the site, to get a Product Owner from the LAA itself given the specialist content being dealt with. The problem is that this role can often be time-consuming. Fortunately, the LAA have stepped up to the challenge!
Our Product Owner has addressed the difficulty of defining the scope of the diverse specialist legal content and being the team’s SPOC (single point of contact) by assigning ‘Content Champions’ within the LAA. These Content Champions have taken responsibility for areas of site’s content – either being experts themselves, or having access to the right people. This will be absolutely vital to the success of the project.
Step 2 – Story-Mapping
Next, in order to understand that content that we will be producing, and being able to prioritise our specification or ‘backlog’ we held a Story-mapping exercise.
This involved gathering the ‘Content Champions’ and the DS content team together.
One of the main advantages of spending time doing this was that we were able to get to know our counterparts in the agency and develop a good working relationship, which will be a further key to success.
In the session we took user ‘Epics’ and broke them down into manageable ‘stories’, each with clear ‘acceptance criteria’. Doing this exercise meant that all details were captured, and the DS content team fully understood the product that they were going to ‘build’.
The session took about 3 hours. It sounds a long time, but it was incredibly productive, and we can only thank our LAA colleagues for sparing the time. By the end of the session, we had a much better understanding of the content that our Product Owner wanted to us to produce. If we didn’t fully understand something, we also knew who to ask!
Step 3 – sprint planning / methodology
Finally, we came up with a specific Agile methodology for running the transition. Agile should not be a burden to a project, rather it should be a framework for success. It, therefore, changes in order for it to fit the specific project being run.
Given the divergence between software and content, we have made some reasonable changes to the ‘standard’ (if there even is one!) Agile framework:
1. Our review process takes place over a week. Rather than hold an hour session at the end of the week with the Product Owner, we send the completed content to the relevant specialists in the agency and over our next spring, they review what we have produced in the last sprint. Any changes or rejections will come into the backlog as either a new user story, or a new acceptance criteria on an existing story. It can then be worked on in the following sprint. If there are no changes required, the content moves to GDS for a second check.
2. Secondly, our board probably looks far more like a ‘Kanban’ board. Rather than simply having a ‘backlog’, ‘icebox’, ‘doing’ and ‘done’ section our board charts the progress of stories in the following way to reflect this process:
Backlog --> Draft content in publisher CMS -->Review by LAA --> second eye by GDS --> Done
3. In the same way as testers and developers work together to build a quality product for the end of a sprint, the content team will also have an ongoing review process within the sprint, whereby content will be checked by a second content designer throughout.
4. Importantly ‘mapping’ is not included in how we define what is ‘done’. Instead, this will be handled at the end of the process.
If you have any comments, or suggestions for how we are running the content transition, please get in touch! Alternatively, if you have specialist content that is due to be transitioned to GOV.UK please also get in touch - we'd love to hear your thoughts!