Sprint 2: who are the users?
Written by Harry Vos
Many different people change forms in local government
After interviewing more people in local government, we found that many different people are involved in changing forms:
- service officers
- customer service managers
- policy owners
- IT relationship managers
- business analysts (in-house or outsourced)
- developers (outsourced)
- technical architects (outsourced)
In more digitally-capable organisations, we also saw these roles involved:
- content designers
- developers (in-house)
- user researchers
The smaller the organisation, the more likely it is that one person or team is responsible for the whole service — dealing with applications, helping users complete forms, processing applications, enforcement of regulations, updating web content, and changing forms. In larger organisations, each responsibility is more likely to be split across separate specialised teams.
Depending on the mix of roles, technical skills and technology suppliers, consideration of the accessibility and usability of forms was varied. It’s important to recognise this because each of these groups of people have different needs. We have to know whose problems we are trying to solve.
Local digital teams tailoring their approach to replacing PDFs and other forms
In more digitally-capable local authorities, and there’s a pattern emerging. In response to the 2018 public sector accessibility regulations, they have a tailored approach to replacing PDFs and other forms:
- High transaction volume: replace with a bespoke accessible HTML form and integrate it with their case management system or customer relationship management system
- Medium transaction volume: use a commercial off-the-shelf form builder to replace it with an accessible HTML form that sends the responses in the body of an email to the right team
- Low transaction volume: delete the form and make the team email address public
When using commercial off-the-shelf form builders, digital teams in these local authorities have spent significant amounts of time trying to convince both existing and potential suppliers to make the forms accessible.
Different tech stacks prevent use of x-gov form builders
A designer in a non-departmental public body said they wanted to use one of the existing x-gov form builders, but their IT team couldn’t support it. To use any of these form builders, you need to host the applications yourself. In this example, the organisation couldn’t host these applications because their tech stacks were significantly different. Installing and maintaining these applications would need refactoring skills and time they don’t have.
Opportunity to make policies more iterative through faster delivery of services
In one recent interview, someone thought that using form builders to speed up delivery of services might, in turn, enable more iterative policies. When it often takes years to deliver a new or transformed service, there is limited time left at the end of a programme to iterate the policy itself after the service goes live.
A form builder may help deliver a new or transformed service in months rather than years. Then if it doesn’t deliver the policy as intended, there’s more time to iterate both the policy and the service.
If this were the case, this closer collaboration between policy and delivery might be an unexpected benefit of using a form builder. While this probably wouldn’t be the first problem we should try and solve, it may be something to test later on.
What we did in the past two weeks
- started to build a shared understanding of what problems members of the x-gov forms community are trying to solve
- interviewed more people working in local government
- contributed to the goals of the tech stream in the x-gov forms community
- learnt about the ambitions of the x-gov form builder team
- started planning a show and tell where suppliers can pitch their products to the x-gov forms community (DM me if you’d be interested)