What I learned in two years of moving government forms online
Two years ago, I started at the City of Boston with a simple yet comically broad mandate: Get rid of paper forms and PDFs. The nascent Digital team had launched the beta of boston.gov, and was learning, iterating, and rewriting content to get everything from the older cityofboston.gov moved over to the new boston.gov.
A *lot* of that content was locked up in PDFs. For years, that was the way most information was posted on the old website. Documents that were mostly content were broken down and rewritten, but Lauren Lockwood, the Chief Digital Officer, knew forms would be tougher. That’s why they brought on a single person dedicated to moving those forms online. She nicknamed me the “PDF Killer”, which I sort of hated but will probably love in like 6 months. I just left the City, so it seems like a good time to review what I did and how I did it.
Over the course of two years, we identified 425 forms and moved 122 of them online. Using a conservative estimate, moving those forms online saved Boston residents just under 10,000 hours. They also made government services much more accessible.
Who am I
I had never worked in Government when I started at Boston City Hall. My background was in marketing, political campaigns, and media. Before this, I worked at the Boston Globe (I have other posts about that). I know a lot about getting people to click on things and getting them to move through websites. What is a digital form if not a really long landing page? During my interviews I talked about using the same tactics I’ve used to increase conversions can probably help with forms. It also turns out that the soft skills I developed trying to drive digital change at the Globe (not to mention knocking on doors for political campaigns) would also come in handy.
Defining the Challenge
I started with a scrape of all PDF files from the old cityofboston.gov provided by one of our developers. It was a lot, consisting of 6263 lines in a spreadsheet. When I first got that email, I wondered what I had gotten into.
I put in my earbuds, fired up a podcast, and started going line by line through the list. That took about 2 months. I would open the PDF, see if it was a form, and log it. I also reviewed contracts and documentation and interviewed employees in the various city departments to ask if they had other forms.
The rest of my team, as they met with departments and went through sections of the website, sent me links and descriptions of forms they collected. After the first year, I had identified 344 forms. 344 is a lot, but having a set goal made it feel a lot more achievable. The difference between “344” and “we have no idea how many but it’s a lot” is important. However, I knew it wasn’t perfect. Too often in government (or any big IT project) we demand that everything be perfectly mapped before we make any decisions about technology. If I waited until I had a perfectly comprehensive list, I’d never actually make progress. After two months, I figured I had found enough to make safe assumptions about the technology we would need. My guess turned out to be right. Over the rest of my time at the city, I found previously undiscovered forms often and Boston creates actual new forms constantly. A year later, we arrived at the 425 number I mentioned above (The team literally added one I had forgotten to document last week).
To keep myself organized, I created a GitHub repository and logged each form as an issue. It’s a bit weird, but Github Issues ended up being perfect. Issues let me include lots of information about each form, attach files and links, and use labels to group forms together by department, complexity, and technical requirements. Github Issues also plugs neatly into a number of Kanban tools. I’ve used Waffle.io, Zenhub, and most recently Github Projects. Having the forms in GitHub was also helpful when I left the City, since the person who took over this effort could simply check out the repo.
Technology
As soon as I started tracking forms, I also started figuring what I was going to use to bring them online. Far too often, governments (or any large organizations) feel the need to perfectly map everything before making a decision. I knew that the only way to learn which features we really needed was to start moving forms online and see what happened. We’d learn as we go.
After a bit of research, I made a few assumptions and went through a bid process for a web form tool. We solicited three bids and procured a partner, SeamlessDocs, as part of a pilot program (Other tools I’ve looked at and liked for creating online forms include Citygro.ws and Screendoor). We also built a page type in the boston.gov content management system that allowed us to embed a form so it looks like a native part of the site. A consistent and beautiful user experience is one of the City of Boston Digital Team’s goals.
The goal of the pilot with SeamlessDocs was to move fast and learn. (SeamlessDocs was great for this). I wasn’t trying to fix every department’s process. I kept my focus on our team’s core goal: eliminate paper forms and PDFs and let people submit information online. In a way, the massive number of forms in front of me made this easier. If I encountered a form with complicated technical requirements or a complicated workflow behind it, I could table it and move on to another one.
One other key piece of technology was G Suite. All of our submissions were handled via Google Drive. If we didn’t have that (Or if SeamlessDocs didn’t have out-of-the-box GSuite integration), I’m not sure I would have been able to make the progress I did.
There are three major technical things that I wish I had started thinking about sooner.
- Workflows — I explain lower down why I’ve avoided process change, but any form that requires multiple steps of approval (Customer submits, Jim signs off, then Jane signs off) I skipped over.
- Payments — A large number of forms (about 86) require some form of payment. Even a $5 filing fee adds an entirely new layer of technology. After a six-month detour trying to build an integration with the City’s current credit card processing software, I realized that we needed a more modern tool. We’ve tabled forms that require payment until we have one.
- Web Applications — Some forms aren’t really forms at all. There are individual forms or clusters of them that only moving online won’t really help. For these, we need to either build or buy web applications that provide a better solution.
One example is the form to order a copy of a death certificate. Traditionally, you would submit a form requesting a certificate. If the City had it, they would send it to you. If they didn’t, they would tear up your check and send you a letter saying they didn’t. Replicating that online would be terrible for both the user and the City. The application we are developing will let users search the database and *then* order a death certificate when they’ve found the certificate they are looking for. We had to flip the process to make it work.
Process Change
Getting city workers to accept online submissions rather than traditional paper ones is the bulk of this work. On average, it took me about 30 minutes to make a digital form and five weeks to meet with, earn the trust of, and get buy-in from the employees who would use it. Even if they were excited, the nitty gritty details took a lot of back and forth.
On average, it took me about 30 minutes to make a digital form and five weeks to meet with, earn the trust of, and get buy-in from the employees who would use it.
I found success by minimizing change as much as possible and giving them clear choices. When I met with a department, I would give them three options for receiving submissions:
- A submission emailed to them.
- A PDF of the submission dropped into a Google Drive folder.
- A line added to a Google Sheet spreadsheet with the submission data.
Some departments had sort-of insane business processes for submissions. If I tried to change those, I would spend a whole year on a single department. By focusing on the priority, moving forms online and making it easier for the customer, I could make consistent progress rather than be consistently blocked. Some departments moved to a more digital process; some literally print out submitted PDFs and put them in the wooden department inbox. Either way, customers can submit online and the system is saving time.
While I avoided a bunch of process change, there were some takeaways that I think are useful for anyone working to move government forms online:
- There is huge demand to move forms online — I had expected to drag departments online kicking and screaming. Instead, the majority of departments were eager to move things online and thrilled to have a partner with the technical knowledge, mandate, and tools to do that.
- Flexibility about form structure and questions — I initially thought there would be a strong demand for submissions that look exactly like current paper forms. That hasn’t been the case. In all but one or two cases, I was not only able to move forms online, but also suggest changes that made forms shorter, more clear, and more accessible.
- Excited about future change — Early on I began to notice a pattern. A few weeks after I moved a form online, some departments would to reach back out and ask for tools to help them manage digital submission, “This has been absolutely amazing. It would be great if I could approve it and then send it to Steve for his signature”. I thought a lot about the phrase salami slicing. If I tried to change everything about the way these departments worked right off the bat, they would have resisted every step of the way. Moving just a part of their workflow online made them eager to go completely digital.
What’s next
We’ve made a lot of progress in the last year, but there’s a long way to go. The majority of city forms are still paper. There are three specific next steps and two big questions that need to be answered that will help us, and other cities, continue our efforts to digitize government services.
Two big questions we need to answer:
- Who should be doing all this process change? — I’ve been doing it because, well, it was my job to get forms online. I’ve seen that same pattern as I talk with other cities. The tech teams are driving internal process change because a lot of that internal change involves technology. That sort of works, but it also creates a weird dynamic because the tech teams don’t have the training nor the explicit mandate to mess around with other people’s jobs. Would this be better served by a specific team who does have that training and mandate? That might be a service design team. Or something like what Denver does. Or maybe it needs to be integrated into the technology team.
- What even is a form, anyway? — Too often in government, we remain beholden to physical relics as we move things online. I was the form guy. That was different than the licensing and permitting team. It was also different from applications initiatives. But really, this is all information moving back and forth. Do we need to rethink what we call certain things? How do laws affect this? How does customer expectations vary if something is called a form vs. if it is called a permit?
While we figure that out, here are some actionable next steps Boston is currently taking:
- Flexible credit card processing — As I mentioned, 86 forms require some form of payment. To move those online requires an easy way to set up new transactions. I’ve learned over the last year that credit card processing is secretly the hardest part of any online enterprise. Legacy credit card processors have a lot of built-in advantage, but don’t have the flexibility most governments need to add services.
- New forms software — We’ve got a lot of users and a lot of submissions flowing through SeamlessDocs. They are a great tool, but our contract is structured in such a way that makes continued expansion tough. We are working on a new RFP, informed by our pilot with SeamlessDocs, that will let us bring on a larger enterprise-wide tool (this may be SeamlessDocs! They are great!! We just need to see what happens in the bid process). This will also let us offer the digital workflow tools many departments have asked for.
- Get serious about building web applications — Building boston.gov was hard, but a lot of the more complicated parts were filed away to deal with later. Now that the site is up, the Digital team is investing in building out web applications. This involves new talent and a new codebase. The Digital team has had an Applications Developer for a while, and just hired a Product Manager specifically to work on applications (yay!).
Tl;dr
In two years at the City of Boston, I moved 122 forms online and saved residents just under 10000 hours. I used GitHub issues to track the forms (documentation was important) and SeamlessDocs to move them online. Departments were more eager than I thought to move their forms online, and avoiding too much process change was key to getting through so many. The next steps for Boston involve a larger contract for a forms tool and a better way to process credit cards. There are also some meta questions about who should be driving internal process change and what a form really is, anyway.
