This is a test

Details have emerged as to just how bad the bad design was that led to the false ballistic missile alert in Hawaii last weekend. As Jason Kottke points out, Hawaii’s response, to reassign the civil servant who inadvertently issued the alert, while a political necessity, does not help get at the actual problem: that the root cause of this incident is bad design.

In every instance of government service failure that I’ve encountered, there’s an inevitable round of blame and justification that takes place. Some blame the vendors, some the government, and some will simply fault “the system,” usually an allusion to the challenges of procuring technology in government.

And in every instance of government service failure that I’ve encountered, everyone shares responsibility. The government must demand better results, and needs empowerment to take the risks to do so. Vendors need to develop the systems that users need, even when the government or their contract does not require it. And procurement needs to be fixed to make it easier for agencies to work with vendors who can produce better outcomes.

The good news is that we have solved this problem. We have many, many models of this working successfully in various levels of government. With the establishment of groups like the U.S. Digital Service, GSA’s 18F, or California’s Digital Service, government agencies have access to expertise that helps them demand more from vendors, craft better procurements, and empower them to take risks. There is a crop of new vendors in government eager to apply consumer internet practices to government digital services. And there are new procurement vehicles that focus on demonstrating competence in skills that lead to better outcomes in delivery, usability, and user experience.

A perfect example: the State of California created a pre-qualified vendor pool for companies competent in various methodologies used in developing government digital services. Unlike traditional Requests for Proposals, minimal writing was required to win a spot in the vendor pool. Instead, companies built actual software, and demonstrated their skills in the process; skills such as agile software development, human-centered design, open source technologies, usability testing, automated testing, continuous integration, and more. The State of California engaged GSA’s 18F to help in crafting the evaluation criteria.

When Ad Hoc applied for the vendor pool in February 2017, we were given the choice of building one of two sample applications. We chose Option B, which was described as:

an application that will allow California residents to establish and manage their profile and receive emergency and non-emergency notifications via email, Short Message Service (SMS), and/or push notification…[i]n addition, the working prototype will provide the authorized administrative users with the ability to publish notifications and track, and analyze and visualize related data.

The entire exercise took about a month, and involved about 6 members of our team in product development, design, user research and engineering. The end result was a prototype application. The focus of the prototype was to demonstrate our technical capabilities, not to build a working product, but in a short amount of time, we had something that worked, and, dare I say, anticipated some of the issues that would have helped prevent the false alarm in Hawaii.

We are in the relative beginnings of our dependence on technology but far enough along that we have developed excellent methods for building things that work, that anticipate how users will interact with them, and what users will need to do. Government, for a variety of reasons, has been slower to adopt these methods, but there are several well-documented examples of it done right. It is easier than ever for governments to do a test run, take a small project, and make it work.