Sprint 0: setting up for a useful discovery

Update about my first week

This was my first proper week looking at the problems with how public services collect information from users. It has been part exciting and part overwhelming to have so many people interested in what we’re doing.

Tom Read has been appointed as the Chief Executive Officer of the Government Digital Service (GDS). When saying hello in our ‘all staff’ huddle, he mentioned that the digital transformation of government was far from finished, and that we still have thousands of hard to use paper forms. I’m glad he’s interested in GDS solving this problem.

To avoid my weeks quickly filling up with calls with everyone that wants to know what we’re doing, I thought I’d try writing updates here, so the conversations I have will be more focused. As it is mostly just me working on this for now, I have to keep paying close attention to what is most valuable to learn at this point in time.

This work is not GOV.UK Submit being resumed

To be clear, at this stage, GOV.UK Submit is not being resumed. Understandably, people were both excited and nervous when hearing rumours about what the Government Digital Service (GDS) is getting up to. Some public servants are excited because they haven’t seen enough progress in improving paper forms. Other public servants are nervous because they think there are already too many form builders that use the GOV.UK Design System — why do we need another? One supplier that has an off-the-shelf form builder was nervous because they thought GDS was going to disrupt their business.

For anyone that feels a bit nervous, we won’t be working on this beyond March 2021 unless we find unmet user needs and are successful in getting funding. GDS does not need to invest if we learn that others have already solved these problems.

We won’t be referring to this discovery as GOV.UK Submit because we cannot assume that what was promising three years ago would still be the best way to solve problems with collecting information from users. In fact, we’re not yet sure to what extent those problems still exist, given that there are now at least 11 form builders trying to solve similar problems. That is what this discovery is all about — trying to understand to what extent these problems still exist.

What problems are we trying to solve?

By the end of this discovery, I think we need to have a more focused problem statement. Though there are some existing problem statements we can refer to. This came out of the ‘offline submission of information to government’ discovery nearly four years ago:

Two thirds of government services, with a third of all transactions between them, don’t have the resources to run Agile teams required to build digital services.

More than 80% of all services involve users submitting information to government. Many of these service teams report high costs, errors and delays due to paper processing, yet they are unable to move beyond offline because they do not have the resource or the support to do it digitally.

From my initial understanding, many of the cross-government forms community members are either experiencing, or trying to solve a different problem, which is something along the lines of:

Many digital teams across the public sector are forced to duplicate efforts when building online forms for GOV.UK and other online services. This is unproductive, because the time could be spent solving problems that are unique to their service. Having to build online forms also increases the time and cost of improving a service. This limits the number of services that can be improved in a year.

While the problems overlap, I think it’s important to distinguish between these two different problems, as they are experienced by different groups of people. The original problem statement mostly affects end-users, front-line case workers and operations managers.

The problem regularly discussed in the cross-government forms community mostly affects digital teams, though this problem may in turn hinder them from serving end-users, front-line case workers and operations managers.

Is anyone trying to solve the former problem? Is trying to solve the latter problem also helping to solve the former problem? Would solving the former problem also help to solve the latter problem? These are all questions we need to answer.

How likely is it that people will solve these problems for smaller services?

Speeding up the work of digital teams will have some effect on the public sector’s ability to improve smaller services, but it’s still hard to imagine even a small digital team improving how users apply for a licence to burn heather when it gets so few applications per year. If it takes more than a few days for a small digital team to work with the operations team to build it, the costs would probably outweigh the efficiency savings.

From the cross-government forms community, it seems that having small digital teams using form builders can be justified for services used between 10,000 and 100,000 times per year. Could this work for services used 1,000 times per year, or even 100 times? I think we still don’t fully understand what would enable smaller digital services.

The GOV.UK Submit alpha concluded that to produce a simple online service that’s easy to use, every service needed a ‘professional designer’ to collaborate with a ‘change owner’ in two short workshops when using a form builder. This would be cheap enough to improve smaller services.

We need to learn more about how form builders are currently being used in the public sector to get a better idea of their potential to be cheap enough to use with smaller services.

What we did this week

spoke to people to learn more about the problem space
formed a very rough idea of what we hope to learn from this discovery
prioritised interviewing people in local government first (we know a fair bit about central government already from the cross-government forms community)
started writing down some ideas for a discussion guide for in-depth interviews
tested some tools to make scheduling interviews easy
set up things to help our team to collaborate, and share updates here
planned for sprint 1

Next update ->