When designing services or creating content, we always start by thinking about user needs. It’s our first design principle.
The principle states that we should focus on ‘user needs, not government needs’. But with registers, just like all other Government as a Platform (GaaP) products, we’re building something for users within government as well as outside it.
Of course, this shouldn’t make a difference because users are users, whether they work in government or not. This has already been observed by the GOV.UK Notify team, whose main users are government service teams.
Registers are reliable lists of information that can be used to build better digital services. Using a register will mean a service team is only ever working with one accurate and up-to-date list of information, leaving much less room for error.
As well as service teams, we’ve been thinking a lot about who the other users of registers are. We’ve identified 2 other potential groups of users. They are:
- people who collect, store or manage data for their organisation and think they should be using a register
- people who are responsible for keeping registers up to date
Both users are actually the same person – the custodian of a register – only at different stages in the register creation process.
We decided to concentrate on meeting their needs first. Making sure it’s as easy as possible to request, create and maintain a register is crucial if we want more people to use them.
Taking the service design approach
We approached designing the register creation process in the same way we would anyservice. We looked at the process end-to-end and back to front. This means we thought about the entire user journey (including online and offline steps) and concentrated on what might be needed behind the scenes to make the service work.
This isn’t easy, and requires an understanding of the user’s circumstances, as well as the task they need to complete and what can stop them from doing it. Fortunately, having worked closely with a custodian to create the country register, we already had a lot of this knowledge within the team.
Visualising how registers are created
We created a timeline, similar to a user journey map, to help visualise the process of creating a register. This helped us see exactly what support the custodian needs from the registers team at GDS and at what point in the process they’d need it.
We were also able to identify when we could point the custodian in the direction of guidance rather than give them support in person. As we’re not yet at the stage where we can offer custodians around-the-clock support, we didn’t want to create a service in which we became a bottleneck. It’s important that custodians are always able to get the help they need, so we decided to publish registers guidance on GOV.UK.
A few months ago, we published an introduction to registers. One of the reasons we did this was to give potential custodians enough information about what registers are and what they can do. Having this knowledge will make it easy for them to decide if a register is the right way of managing their data.
In addition to these, we’ve recently published history pages for every register we have in alpha or beta. These record the steps that the custodian has already completed and what they’ll need to do next in order to put the register live.
Refining this process will not only help custodians, but service teams, too. Knowing that the custodian has provided useful, contextual information about the register and is committed to keeping it up to date will let service teams know the data is good enough to build services with.
We’re testing our GOV.UK guidance with both existing and potential custodians. Once we have enough feedback, we’ll look at what we can do to improve it.
We’ll also look at how we can improve the way registers are maintained once they’re published. This will require us to build some new tools for the custodians, and we’re starting to think about what they might look like. We’ll have much more to say about that soon.
After we’ve done this, we’ll go through this whole process again to look at the needs of our third user group – service teams.