In April, the day before taxes were due, the IRS’ online filing system failed, just as procrastinators were settling into the annual TurboTax panic. How did this happen, especially before the most important tax day of the year? And why does this keep happening to government websites?
A few days later, the glitch was figured out. It was a technical error related to the master file—the core system that holds all taxpayer information. Former IRS Commissioner John Koskinen proposed that behind this technical error was a very human failure related to ongoing congressional budget cuts, resulting in overburdened staff and a system under pressure. Eventually, it had to break. Still, most of us probably feel that the IRS website should work before tax day, and that precautions should be taken to ensure that failures of this kind don’t happen.
A predictable mess
This isn’t the fist time the IRS website has failed: In 2015, it accidentally leaked tax data for around 200,000 Americans. More broadly, government technology failures are depressingly common. Who can forget the Healthcare.gov disaster years ago when the website launched with forms too complicated to fill out and stability problems that lead it to crash repeatedly. By the end of its first day, only six people successfully enrolled.
Healthcare.gov was ultimately completely redesigned by civic technology companies Nava and AdHoc. Sha Hwang of Nava told Gizmodo the company proved the robustness of the new site by doing a billion load user test. “When building for scale we need to think exponentially,” Hwang said. It seems obvious to say that a successful product meant for hundreds of millions of people needs to be able to handle traffic. In 2014, a year after the initial catastrophe, healthcare.gov was relaunched ready to handle the load, with a faster and better signup process. By 2017, over 23 million people had used the site to sign up for health care.
The failures of healthcare.gov and the IRS are emblematic of the challenges of building what’s called civic technology—technology built to engage the government and the people. Civic technologies like government websites are shaped by the policy they’re supposed to facilitate and the technology available to implement it. Those making websites need to understand the policy, translate that policy into a well-designed site, deploy it as a product online, and make sure that the website works. Aside from security, the key design challenges are always the same: size, traffic, and usability. Too often, governmental sites are poorly planned and don’t address one or more of those challenges.
It turns out, mismanagement and technical errors happen at both the state and federal levels when creating digital governmental services. The giant consultancy Deloitte, in particular, has a history of shipping poor and confusing technology for states including Massachusetts, California, and Rhode Island. The latter hired Deloitte to build their Unified Health Infrastructure Project (called both UHIP and also RI Bridges) for $400 million. The project was supposed to provide a variety of public benefits for Rhode Island citizens, like cash assistance, Medicaid, and food stamps. When it launched in 2016, the system lost applications, slowed down the processing for benefits, and encountered myriad other failures. Ultimately the ACLU sued over the problems twice—once shortly after the program launched in 2016 and again in January 2018.
Despite these failures, the state extended the contract with Deloitte, which was set to end in June, until March 31 2019. Ashley O’Shea spokesperson for the state’s Executive Office of Health and Human Services told Govtech.com that the decision to stick with Deloitte after years of poor service by explaining that“We don’t want to pay for work twice which would happen if we shifted to another vendor.” She called giving the company an extension “an opportunity for Deloitte to bring the project to completion.”
“We continue to work closely with the State of Rhode Island to prioritize and fix the outstanding technology and business process issues impacting residents,” a Deloitte spokesperson wrote in an emailed statement. “The agreements we have reached with the State and the investments we have made demonstrate our good faith, our dedication to the long-term success of RI Bridges, and our commitment to the people of Rhode Island. We are an organization that not only stands behind our work, we step up.” Deloitte didn’t clarify what they were fixing or how they would do that, and did not respond to follow up emails.
The long-term fate of Rhode Island’s public benefits program is up in the air, but the state has said that after March 2019 it intends to try to find a solution for a long term partner to run the program—one would think it would look to a new vendor. Still it’s unclear why failed partnerships between private firms like Deloitte and government agencies continue to occur across the country. How many other problematic vendors or poorly made products exist out there? And what can be done to stop it?
A recurring error
One of the biggest reasons that these failures keep occurring could be because many public servants simply don’t understand technology and how it should be built for the government. If a public servant or governmental department hires a company to build a website, do government employees understand enough about how a digital product should look, feel, and function to adequately understand when a contractor is messing up or delivering a bad product? In case the failures described above haven’t made it abundantly clear, building technology to serve a government constituency is a much more complicated undertaking than it first appears.
“It think there are several factors that can cause failure in any complex project, but that are magnified in government both due to the complexity of the challenge and the responsibility of the service [to] serve 100 percent of users,” Hwang explained.
From an organizational point of view, landing a government project can be a confusing and bureaucracy-ridden hell that a contractor needs to overcome. Other hurdles include understanding the complexity of the project, or even finding the right, knowledgeable public servants to work with. Infrastructure considerations go beyond scale and security. Technical integrations need to be deployed properly. For example, in the case of healthcare.gov, the site’s original architects failed to make a working sign-up system and user database that could be used by millions of people.
And then there’s the issue of culture, and more specifically the expertise within a government entity. In the case of handling taxes online, that digital system is written with code but shaped by policy. That requires two kinds of expertise: understanding of bureaucratic policy and a digital literacy to see how that policy is reflected in a website. Certainly a government agency can be expected to understand the policy it needs to execute, but the most challenging problem is that there might not be technical and design literacy within a government agency, such that it can do things like user research, which ensures that technology actually works the way it’s intended to. By interviewing and observing users, designers can determine how a website is failing the policy and try to fix it.
It just has to work
Despite being more necessary than ever, digital literacy hasn’t permeated deeply into the folds of the government. As we’ve seen, public servants often lack the expertise to know how to critique and test technology, and return poorly designed or faulty technology for improvement. The solution isn’t teaching civil servants how to code but instead teaching what kinds of digital tools and products are usable, and what expectations they should have from a product so we can avoid failures like the IRS website. It’s not just a software problem but an understanding problem.
Federal and local sites have to work, there’s no room for them not to. More importantly, civil servants need to have design literacy and technology support when working with outside vendors. Cyd Harrell, a civic designer and former head of product at Code for America, stressed, “It’s one of the things I’ve discovered of my now several years in civic tech, our public servants work incredibly hard with incredibly challenging tools. And even though governments don’t provide the public with great interfaces, what they provide their staff with is even more difficult to work with.”
And there are options in the form of resources created by USDS (United States Digital Service), 18f, and Code for America. Many public servants don’t know that they can access those cases studies, design resources, and guides, or that they can work with USDS and ask for help.
Building a site that securely stores thousands, or even millions of people’s sensitive data while they are accessing it in massive numbers, and making sure it’s user friendly, is not an easy task. But these are the design requirements of civic technology now. No one gets to opt-out of taxes, even if the website is down.
Caroline Sinders is a design researcher and artist working at the intersections of emerging technology, design, and policy.