Meet Nava, A Startup That Wants To Fix The Government's Crappy Design

A couple news organizations wrote articles about healthcare.gov after I left.  I'm not mentioned by name in this one, but I'm in one of the pictures.  I think that the article is fairly reasonable.  I pasted it below, but it's probably nicer looking if you view it on Fast Company's website.

---

ENGINEERS AND DESIGNERS WHO REFINED HEALTHCARE.GOV ARE ON A MISSION TO TAME THE GOVERNMENT'S UNRULY DIGITAL PRESENCE.

After the disastrous launch of Healthcare.gov, a website promising easy sign-ups for health insurance, President Obama corralled a team of top software engineers from companies like Google, Facebook, and Twitter to fix the glitches. Now, Nava, a startup composed of people who rebuilt the website, wants to radically improve other government services, too.

The timing couldn't be better. As Congress legislates new policy, agencies are increasingly tasked with implementing programs that rely on software. But those programs tend to be overly complex, run over budget, and rarely work as planned. For example, the Department of Defense and Department of Veterans Affairs spent $1.3 billion on a program to build an electronic health-records database and abruptly stopped the project in 2013 after it failed to progress as planned. More staggering? In the past 10 years, about 96 % of all government IT programs that cost over $10 million were deemed failures, meaning they didn't meet their budget, timeline, or user expectations.

The problem to solve becomes, "how do we reimagine solutions from the end-user perspective, build something that won't catch fire, and redefine the problem so that it's not only about how to build robust technology, but how to deliver better outcomes to people?" Nava's Rohan Bhobe says. Nava, in other words, sees itself as creating "software that radically improves how our government serves people"—right down to the last design detail. 

Nava's Genesis
First for a little back story: The engineers and designers recruited to oversee the Healthcare.gov overhaul were part of what Obama informally called tech surge. Its initial purpose was putting out the fire. After the Healthcare.gov fiasco, Obama established the United States Digital Service (USDS), a group of elite technologists tapped to overhaul the government's digital systems (who are profiled in the July/August issue of Fast Company). Nava emerged from similar circumstances. Nearly all of the 10-person startup was recruited to work on Healthcare.gov during the tech surge phase and spun off afterward to form a private company.

• Here are the key lessons the company learned from fixing Healthcare.gov—and how they plan to apply them to other branches of government.

Strong Technical Architecture
Before you can create a great end-user experience, you need a strong technical base. Nava advises taking a microservices architectureapproach—a way of developing an application as a suite of small services versus the monolithic approach of building an application as a single unit—to construct nimble web systems. "Rather than having a giant software application where all developers would be working on the same codebase, using the same technical stack and tools, a microservices architecture breaks that all up into a series of 'black boxes,' with specified interfaces between the black boxes," Bhobe says.

Healthcare.gov's site architecture resembles a services-oriented approach, but isn't 100% there. "It wasn't designed that way upfront—you do have separation between systems, but the interfaces between systems are not very clean," Bhobe says. "The work we've done so far is designed to be service-oriented. We've helped move things that way, but the work isn't complete. It could be cleaner, and hopefully will be in the coming year."

Since microservices architecture is composed of many different, independent software components, it can be upgraded and programmed much easier. It's typical for multiple development teams and contractors to work on large software projects. This approach means that each team can use its own technologies and tools and make sure its portion of the project runs exactly how it's supposed to, instead of worrying if changing one part of the codebase to benefit a service will have ripple effects elsewhere.

"The law changes, requirements change, vendors and contractors change—how do you design a system that is future-proof?" Bhobe says. "Your architecture can be something that helps with that and microservices architecture is something that makes sense for a lot of government websites."

Translating Paper To Pixels 
The less complex the software better, Nava says. But that's easier said than done, especially when you're translating paper to pixels. Managing how much information a user needs to divulge—and how the digital system processes it—becomes a new challenge.

"From a design perspective, general problems come up from a transition between designing for paper forms, then designing for websites," Sha Hwang, Nava's design lead, says. "On paper you need to handle all of your edge cases, you need to have every possible question that could possibly arise to fulfill your decision tree. A lot of the work we did last year for retooling the Healthcare.gov application process was figuring out which questions were necessary to ask of everyone and which ones were only necessary for certain people."

Instead of having one online form with dozens of entry fields on a single page, the new Healthcare.gov application process asks a few general questions—like income and household size—then directs you to more specific questions based on your replies.

A Refined Process
Retooling the process behind how the government's technical projects are managed and delivered is pivotal in changing perceptions about the possibilities for software.

Because of its size, the government is mired in complicated processes that involve many, many people. It also has production schedules where massive chunks of a project are submitted at a single time. Nava says it's important to deliver working software frequently, rather than large versions at infrequent intervals.

"We're taking a proactive approach where we think about process and introduce practices like continuous delivery, favoring working software over documents and spreadsheets, and convincing by demonstration," Bhobe says. "That helps dispel unfamiliarity with some of the techniques we have."

Government, and most large organizations, have huge numbers of people who are working on projects. On Healthcare.gov, many employees and contractors were using instructions handed down via email and working off of information contained in documents for long periods of time before seeing how it would be communicated online.

"When you have any abstraction, it's less clear how the consumer would be affected," Nava's Kalvin Wang says. "Looking at the website, it's easy to see how a user would feel when interacting with the product as opposed to looking at the intermediate spreadsheets."

Speaking directly, and in person, with the decision-makers helped to alleviate these pain points. "Removing distance has made the process a lot clearer and a lot cleaner," Hwang.

Next Steps
Nava sees many opportunities for well-designed software to solve problems in government.

"Tech surge showed that empowering the the right people with the right approach does make a huge difference," Bhobe says. "There can be a partnership between what the government is trying to do—deliver services to people—and what people from the Valley are able to bring in modern approaches to software design and user experience design. Healthcare.gov was maybe the most visible, but not the first time, that there's been a failure of such a large government software initiative."

On the federal level, taxes and student loans are top priorities. Their ambitions also reach to state-administered programs.

"The problem isn't just at the federal level, which is where we're working," Wang says. "If you look at food stamps, which are county- and state-organized, the systems there are just as problematic for people who use them. You have to take an afternoon off work and get childcare and to go in and wait in line for three hours to submit a form that is really confusing and then in a few weeks you have to wait in line to get back another form that's even more confusing. And a lot of these are totally fixable problems, we just need more tech people to be working on them."

The newfound optimism about the government's technical future is inspiring, but can a 10-person startup really make a difference? Perhaps the Healthcare.gov embarrassment was enough to open the eyes of political decision-makers and software developers.

"Like Captain Planet, with our efforts combined, we can change government software practices and the way services are delivered," Bhobe says. "We'll need to push from all sides—from outside government and from within—to start turning the ship."

Right now the startup is conducting outreach and exploring new avenues for its expertise. If Nava's mission resonates with you, thecompany is hiring.