LocalGovDrupal Camp 2026 - Building Better Forms

I’m at LocalGovDrupal Camp, going to sessions, finding out about things that I can pass on to you, the localgov digital strategist-practitioner. I’m in a session being run by Alex Sturtivant of the Royal Borough of Greenwich talking about better webforms, and this is what I’ve taken away from it:

Often a form is the first - or indeed only - meaningful interaction between residents and the council. The quality of a form creates a lasting impression on a user, and indeed poor forms can drive users away from the online service.

Forms which look like they come from the era of Windows 95, which are difficult to build and use, which have accessibility issues are the worst. Building forms should be the responsibility of Content and User Experience Designers to ensure consistency of quality. And, of course, that Content and User Experience design team should be working to published form design guidelines. These guidelines can also be useful to refer to in a dispute with a service area if the form they are requesting does not make sense.

A good forms engine enables form builders to create reusable components rather than having to keep reinventing the wheel slightly differently each time, and will also enable easy interaction to other systems rather than relying on email and .csv download. It should also enable the ability to encrypt submitted data so that only authorised users may see it after submission. A good forms engine should also be able to include basic case management and workflow as part of the engine. It should also enable the site owner to configure data retention policies to purge old data after it’s no longer needed to be held by the forms system - both global data retention policies which would be applied to all forms by default, as well as specific policies for specific forms where there might need to be a different policy for that particular case.

Once a form has been built and deployed, it should not just be left sitting there - just as content should regularly be reviewed, so should forms. Does the design which presumably worked when it was published still work a year later? In retrospect, a year later is it actually a pain to use? Are we eating our own cat food - are we actually using our own forms ourselves as part of our own council interactions as citizens as well as in our roles as staff members building and testing forms?

There should be facility to start a form and complete it later - not just before the initial form submission, but after a submission - it should be possible with a particularly complex form for the user to enter their initial submission with the core information to get their report or request into the system, and then provide supplementary information later.