“We need to be about the business of perfecting an imperfect law.”
That line caught my ear, but not because I’m interested in the future of healthcare in the US. I am, in fact, quite interested in the future of the ACA, but not as interested as I am in how to make laws and policies that get the outcome they intend. This, to me, is the underlying non-partisan issue, the how of government, that we miss in the great debates about what laws are the right ones for the American people.
At Code for America, we’re convinced that government can work in the 21st century. Our focus has been on implementation in a digital age, using the user-centered, iterative, data-driven approach that’s worked to make the technology services and platforms most of us use in daily life now spread so quickly. (What’s their secret? They work for their users and provide real value.) The movement to update government operations has had plenty of wins: the long list of projects the USDS has tackled, like the healthcare application for veterans , the do-over of the child welfare system at the State of California , and dare I say hundreds of projects by Code for America Brigades, fellows, and staff, including an easier way for Californians to apply for food assistance called GetCalFresh . Just last week, I saw the City of Oakland’s new Rent Adjustment Program , intentionally redesigned using the user-centered, iterative, data-driven approach that is common to systems that are, if not always a delight to use (who loves complaining about their rent?) at least, in the words of Scott Silverman, an inaugural Code for America fellow, “simple, beautiful, and easy to use.”
But we all know that when laws and policies miss the mark, a better implementation only mitigates the pain. Or, as Andrew Maier, another CfA fellow turned USDSer, put it, “digital is a manifestation of policy.” But digital is also a path to better policy. Less visible than the wins of better digital services is the recognition that the same user-centered, iterative, data-driven practices can work on those policies themselves, and eventually on our laws.
This isn’t a new idea. Even in Code for America’s history, the recognition that the flaws and needed fixes in policy become apparent in the digital implementation — with clearer and faster feedback loops than in an analog world — have been there since our very first projects. Recently, I rewatched the video of Joel Mahoney , a 2011 Code for America fellow, talking about a project he did for the City of Boston that helped parents figure out which public schools their children were eligible to attend. Boston had decided to promote more kids walking to school, so the policy stated that students who applied to schools within their walk zone (1 mile for elementary school, 1.5 miles for middle school, 2 miles for high school) would be given higher priority in the school selection process. It’s only in the implementation, a basic web app that allows you to enter your address and the age of your kids and maps the schools in the radius (taking in a few other eligibility factors), that the edge cases appeared. And it’s only in working with users (in this case the parents) that the flaws in the policy appeared, like student homes that were 1.5 miles from the school as the crow flies, but many more miles of actual walking because the route crossed, say, the Boston Harbor. Making these and other use cases visible — to parents and to school department officials — made it much easier to understand where the policy needed adjusting. Compared with the nation’s healthcare system, this policy is several orders of magnitude simpler, but the fact that Code for America projects have been helping policies iterate and get closer to the intended outcomes from the very beginning is still significant.
But now we know that even healthcare policy can in fact benefit from this kind of iterative process. Last year, regulators at the Health and Human Services Agency in Washington, DC were charged with implementing a law called MACRA (the Medicare Access and CHIP Reauthorization Act of 2015.) The MACRA team wanted the HHS Digital Service team, led by Mina Hsiang, to build the website that would implement this law, designed to allow Medicare to pay more for better care. What usually happens is that before regulators engage a tech team around a website for users (in this case, doctors and other providers of medical care), they spend many months of study and research, producing a specification describing in great detail the rules the web application will encode. Mina proposed that the team writing the regulations give them an early draft in about a fifth of the time it would normally take them, and let her team do an early version of the website based on that draft.
It’s normal practice for a tech team to test a site with users early in the development process; what was different this time is that the regulators could also see how users experienced and interpreted the rules they’d written, and change their language based on user behavior. They could then test the new language in a subsequent (still draft) version of the site, as the tech team put out new versions of the website to their test users. They did this four more times before the regulators called the rules final. The MACRA regulators reported that they’d just written the best rules of their career, having benefitted for the first time from real-world feedback during the process.
This enthusiasm from regulators and other policymakers is not unique. If you attended the Code for America Summit last fall, you’d have heard this many times over on the mainstage and in the hallways. Tom Loosemore , formerly of the Government Digital Service in the UK, worked with policymakers to take an approach very similar to Mina’s, and reported similar “aha moments.” “I’m realizing that what I’m holding is 500 pages of untested assumptions,” one of UK policymakers said of his own work, when he realized what he’d been missing by not being able to test with users. Here’s Tom’s talk at the Summit.
And no one’s been more enthusiastic about this iterative approach than the woman who was until recently the head policymaker of the United States, Cecilia Muñoz. Cecilia was the head of the Domestic Policy Council at the White House under President Obama, and was one of the biggest West Wing champions of the United States Digital Service from the beginning, or more accurately, when it was still just an idea. Cecilia seemed to know instinctively that the practices of the tech folks she met were just as relevant to her team. She became known for speaking up for user needs, often in the form of data from user testing, when more conventional policymakers on her team pushed their (usually untested) assumptions of what would work. She started exhorting her colleagues not to wait until everything substantive was locked down to invite tech people to the table, but rather have them part of the process of strategy and policy development from the start. At the Code for America Summit, describing her experiences working with tech folks, she said: “This is the most transformative thing I’ve seen in my eight years in government.”
All tech starts out imperfect and evolves over time based on user needs and user behavior. We now have examples of rule makers testing with users and evolving the rules based on user needs and user behavior. To do this, the process of rulemaking, and eventually lawmaking, must be redesigned. And we have a long way to go before this is a well understood practice; it’s still very early. But perfecting imperfect laws is the best chance we have; as the complexity of our society increases, our chances of getting policy right the first time goes down rapidly.
