How to make a form

Published in

San Francisco Digital & Data Services

6 min readMar 9, 2021

A closer look at 3 form stacks for government service delivery

paper PDF form with 40 fields and messy writing on top next to a screenshot of a digital form with headlines and descriptions — Building permit forms on paper and digital

A form is a unique place. Design, data, content, translations, and integrations collide, even more than on the rest of the internet.

At San Francisco Digital Services (SFDS), we partner with City departments to deliver services digitally. In 2020, we made more than a dozen forms — forms to sign up for your COVID vaccine or get a grant for your small business or get a building permit.

Forms are often the most important part of a service. Constituents have to use them to give the City information. Then, the City has to use that information to administer complex programs. It’s where the rubber hits the road.

In government service delivery, forms are notoriously bogged down by change management and process changes for government agencies. (Read the canonical “What I learned in two years of moving government forms online” from Josh Gee for more guidance on those challenges.)

Though that is part of the challenge, our team also struggles to create and scale a repeatable process to build forms consistently across our growing team and many different City agencies.

One form process to rule them all?

We decided to ask other people how they do it. In December, we launched a survey of other government form writers and builders to see how they are building forms for their constituents. Maybe someone else has solved this problem for us?

We learned: everyone is doing it their own way, and everyone is frustrated. Whether using off-the-shelf tools or a custom solution, teams hit the wall at process and technology limitations.

Team processes

Almost all survey respondents said that who is responsible for a form depends on the project. In the triad of engineer, product, and design, every role may be responsible for a form depending on the team.

Engineers are almost always involved in building the forms.
Content designers and subject-matter experts were the second most common role to build forms.
In some organizations, like the City of Philadelphia, product managers build standard forms and engineers build custom forms.

Let’s look at 3 different form stacks and how they enable teams to serve the public:

Semi-automated forms
Off-the-shelf tools
Custom solutions

Semi-automated forms

When COVID started, many courts closed. The team at Suffolk Legal Innovation and Technology (LIT) Lab realized there would be no way for people to submit forms even for emergencies, like restraining orders or requests to stay evictions.

The LIT Lab signed a memorandum of understanding with the Massachusetts State Courts to accept electronic versions of completed forms.

However, the Courts would still only accept PDF-versions of the forms. So, how to make the forms digital in an accessible and equitable way? Rather than give users a downloadable PDF, the LIT Lab used docassemble and wrote Python packages with a set of basic questions to automate the creation of the digital form.

Screenshot from a digital form with the title What is your name? and the fields for First Name, Middle Name, Last Name, and suffix — Court Forms Online Name page

Then volunteers revised the electronic versions before publishing them.

Once users fill out the form, the tool populates the PDF form and emails it to the courts.

See Court Forms Online for the final product.

See the Legal Innovation and Technology Lab (LIT)Github for their scripts.

There are places where this solution could be better. But this solution is 1,000x better than a PDF form.

Off-the-shelf tools form stack

This is the most common way teams build forms right now. Since I am closest to the form stack we use at SFDS and this is our approach, let’s look closer at ours.

At SFDS, we had been working on a custom form tool, but before the pandemic hit, we decided to deprecate it to focus on other product priorities.

So early in 2020, we procured Form.io as our form builder. This is the core of our form stack.

We use it like City of Philadelphia uses JotForm, City of Austin uses Formstack, and the State of Georgia uses Drupal’s built-in form tool. If you are making this procurement decision for your City, check out the amazing Digital Forms Research and Evaluation and the 107-category form evaluation criteria from the City of Austin.

Our off-the-shelf software for integrations are:

Automate.io to send data into Airtable
Airtable to show form responses
Twilio for text notifications
SendGrid for email notifications

We built custom integrations including:

Micro-services for sending data to databases
Workload triggers (like calculating vaccination phase)
Sending data into existing City systems like Accela and Salesforce

We have also built front-end integrations that validate City-specific data in the form, like connecting an address to the City’s parcel codes.

One of our biggest challenges has been in form translation. Aside from the challenge of human translation in 3 languages, small bits of UI labels (like the “Drop file here” instructions in an upload field) get lost in the handoff to our translation vendor. We have now procured a new translation vendor and are integrating Phrase as a tool to standardize and simplify the process.

We wrote a style guide to make writing forms easier. We are now working on a form question library. (It started off as an Airtable, morphed into a Google doc, and we’re still figuring how it will be most useful.)

We also started a cross-disciplinary forms working group across product, UX, engineering, and content design to surface and resolve ongoing form challenges like data collection standards and form engagement tracking. We haven’t ironed out all the problems yet, but we’ll let you know when we get there.

See our form.io theme for SF.gov and our GitHub project.

Custom solutions

The most mature custom solution in our survey was the GOV.UK service builder. The service builder includes accessibility, GOV.UK components, integrations, security, payments, and notifications all built in.

The service builder benefit is that it “takes care of the small things and allows the team to focus on higher value items,” according to our survey respondent. They noted about 60% of questions are the same from service to service, and 40% are unique to that service or form.

Here’s the alpha of the tool they built to design and prototype forms if you want to take it for a whirl.

Even within this mature tool that makes launching a form easy, they are continuing to refine how configurable or flexible this tool is for digital teams.

What now?

Forms are so variable. From year-long permit approval processes that touch 5 departments to a 2-minute signup for a mailing list, it’s hard to find a one-size fits any government.

Someday there will be a standard for forms in government, like the UK federal standard that can be used by any government entity. If anyone is currently working on that, please let us know!