The internal side of a public government digital service

Product Design

THE BRIEF

In 2015 I joined a service team working on a large public digital service with a internal aspect. When I joined, the service was in private beta. Most of the effort up to that point had been focused on the public facing side of the service. However, there was a large group of users behind scenes trying to deliver the service and that were clearly under a lot of strain. The product owner recognised this but wasn’t sure how to go about solving the problem. There had been some research conducted with staff using the service but nothing had been done about it yet.

SORTING OUT THE BASICS

One of the biggest things staff were having trouble with was finding a citizen whose case they were working on. At the time all the citizens’ names were listed as links on a very long page. Every time staff wanted to find a person they would have to use their browser’s inbuilt search functionality. We clearly needed to make this simpler so that staff wouldn’t have to waste time with such a basic activity.

We wanted to move to a model where staff would easily access the cases by presenting them with only a list of the cases they were working on, a case list. However, staff had different roles to play when dealing with cases so it wasn’t as simple as assigning cases to them and then displaying those cases to them.

One staff member would interact with the person face to face and would be a consistent point of contact for a citizen. For this role it was relatively straightforward. These staff became the main owners of a case and they could see a list of cases they ‘owned’.

However, there were other staff that would process things in the background. There could be multiple staff of this nature working on one case and who was working on it could change at any time. The user researcher and I spent a lot of time sitting with these staff and prototyping. What we ended up creating was the concept of a ‘supporter’ role.

Essentially we enabled these staff to tag themselves to a case, a bit like the concept of a ‘watcher’ used in other popular software. This meant that we could display the cases staff were ‘supporting’ in their case list. They could also easily add or remove themselves from a case at anytime.

SETTING UP A DEDICATED TEAM

At the time, due to the scale of the service it had five development teams. When the case list was first released, development teams were assigned work based on capacity rather than area of focus. Designers, some of which I was line managing, would work across the development teams.

However, after the success of the case list and by working with a user researcher to to highlight the importance of getting the service right for staff we set up a dedicated team to work on only the staff facing side of the service.

By having a dedicated team, we built momentum and ownership to fix the problems staff were facing. The whole team regularly attended user research and design studios. We could also be a lot more experimental. For example, we re-located the whole team to a call centre to do some quick changes with staff and set up the ability to A/B test designs, a first for the service.

When I left, there were still a lot of problems to tackle but I hope that through some of ways of working I introduced, the service was and is in a better place to do so.

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