An internal government digital service

Product Design & Management

A ROCKY START

In early 2017 I joined a service team working on an internal service within a large government department. The service had gone through a discovery phase but I had been told it was having some difficulties getting it’s alpha off the ground. Also the designers, researcher and product manager had just left. The head of design for the department at the time warned me that this was going to be a difficult project and it needed some strong design leadership.

UNCOVERING THE PROBLEM

In the first weeks I sat down with each member of the team to find out a bit more about their role and some of the history of the project. It turned out some great work had been done but the team was just lacking a bit of direction and had some tricky stakeholder relationships.

SERVICE GOALS

One of the first things I did was define the goals of the service. They were already loosely in the team’s heads but I wanted to make sure they were concrete, within our control and measurable. Once they were agreed on, I created a poster to hang up in our space. The team referred to it to make decisions and aid prioritisation.

DEFINING THE FIRST RELEASE

There were multiple teams that were going to be using the service and multiple sets of end users that would be affected by it. The user researcher and I mapped out all the different combinations and looked at what groups we should start with. We realised that one set of end users had a journey that we could use to form the basis of all journeys. Therefore, we decided to focus on a small group of users that primarily dealt with this journey.

By picking out one group of users and one journey we were able to really focus our efforts. We started doing more user research with them. We got to know them really well and them us. We were taking out iterations of a prototype of the service almost every week. They really got to know our process and started feeling a real sense of ownership.

It also helped with stakeholder relations as we could focus our efforts on the key stakeholders for the one journey but also make sure our others were kept informed through monthly show and tells.

A BIT ABOUT PROTOTYPING

I had a prototype that had been created by the previous designer but I essentially started again given our new focus. Most prototyping in government is done mobile first and straight in the browser using HTML, CSS and JavaScript alongside what comes with the GOV.UK prototype kit.

Most of the basic components you need to build a service are in the GOV.UK design system and are compatible with the kit. However, internal services often need a bit extra. For example, adding multiple items to a list or conveying the status of something.

While working in government, I and other designers worked to standardise these extras and feed them into the design system. You can see an example of this work and some of my contributions in the Ministry of Justice design systems backlog.

BUILDING THE FIRST RELEASE

While I was prototyping and visiting users with the researcher we were building the service bit by bit. When we were confident about an aspect of the service, the developers and I would sit down and write stories. The service team all sat together and had daily stand ups so any questions that came up during development could be easily addressed. When stories were built I would also sit down with the testers and go through any issues that may have come up at that stage.

As we were in the final stages we tested the service with a director general of the department which is common practice in government. These roles can often be very detached from what is going on on the ground so helped them and us to be more connected.

THE RELEASE

When we had got to the point that we had built our first journey, we released it to the team. For the first few days the whole service team relocated to the team’s office. Obviously this is not possible for all services but because we had such a small initial user base that were all co-located I felt it made sense to be there to handle any issues that might arise. Plus it’s an exciting thing to see your users use something you have built for the first time and why shouldn’t the whole team experience it first hand.

FURTHER RELEASES

Our first release only catered to one journey. So as soon as we were happy that our first release was running smoothy we focused our attention on the next. We followed a similar process for the next journey and all after that, picking a team to focus on and doing an initial release. We gradually rolled out the service this way to all the internal teams over the course of five months.

OUTCOMES

Getting some critical data users needed used to take 10 days but only took an hour with the new service.

Data about requests made to a third party supplier that was also reported on by the supplier was now in-house so the department could more accurately report on how service level agreements were being met.

Doing what the service was replacing used to take over 15 minutes but took only 5 minutes in the new service.

Unfortunately, I couldn’t include any photos or screenshots of my work on this service due to it’s sensitive nature.