My niece, Nancy Seybold, lives in Washington D.C. and is a member of the loose community of website designers who serve the vast U.S. government healthcare and nonprofit sector. Although she has not been involved in the design of the disastrous website for the Affordable Care Act, I figured she would have heard the local scuttlebutt. So, when we sat down over coffee at her home in D.C. last week, I asked for her take on what went wrong with the Healthcare.gov site.

(Have you noticed that the site’s name is wrong? It’s not a site about healthcare, folks, it’s a site for buying health INSURANCE. Most of the State-based exchanges have the right idea. For example, Washington State’s Health Insurance Exchange is called WashingtonHealthPlanFinder.org. By the way, it’s the state exchange with the highest level of enrollments to date.)

Last Minute Decision to Disallow Anonymous Browsing

Nancy corroborated some things I had deduced, but surprised me by revealing something she had heard—there was a last-minute policy decision not to allow consumers to see available plans and pricing without first registering on the site.

Not only did people have to register, they had to apply for eligibility for subsidies before they could even see the plans on offer in their own states. Nancy specializes in user interface design and information architecture. She knew what a disaster such a move would be—all of a sudden millions of people would be hitting the back end of a very complex engine.

Flawed Workflow Design As Well

At first, I thought that the entire website design had been reversed at the last minute—that it had been planned to allow folks to browse and iteratively compare and contrast health insurance plans before enrolling. That is how most e-commerce sites work. It’s also the way that Massachusetts’ early forerunner of the national insurance exchange originally worked. But, no, the workflow for the healthcare.gov website was planned to be “apply first,” then search for available plans. As of Spring 2012, according to the self-congratulatory article about the open source user interface design process written by Alex Howard and published in the Atlantic on June 28^th, the workflow on the beta site already looked like this:

www.healthcare.gov

That’s clearly a recipe for disaster! Data from the Massachusetts Insurance Exchange revealed that prospective customers browsed and iterated on average 18 times before applying and enrolling.

Nancy’s reaction to the Atlantic article:

“You’re right, that does suggest they had this [bad] workflow idea from early on.

There is a lot of patting themselves on the back but they don't talk AT ALL about the two things I think went wrong from the get go (all related to who is in charge);

1. Systems integration. It's all very well and good to talk about how cool your front end is and open source, but the darn thing has to talk to all these back-end systems housed in and run by other entities, NONE of which are open source. You need serious dedicated integration teams working on that, not a bunch of latte-sipping hipsters who want to build the next Twitter. I find the complete lack of visibility into that telling. That was going to be hard, expensive, and kludgy no matter what.

2. User testing. Yes, they mention A/B and multivariate testing, but it sounds to me as though they are talking about a) once it is up and running (hello, too late) and b) not for the actual workflow parts of this site.

As we discussed, this site had to work for people of a range of web sophistication and for audiences with no experience with health insurance. I don't care what kind of whiz bang tools you deploy to discover whether a red or blue call to action button works better (been there, done that, have the t shirt—if the call to action is flawed it doesn't matter what color the button is)—they needed to do simple workflow prototyping, which could have been done on paper or simple PowerPoints—to see how well tolerated the basic assumptions were. More basically, they needed to CHALLENGE their own assumptions, test different workflows, and understand how to balance the requirements of the project in terms of outcomes with the often fractious behavior of real people confronted with a complicated process.

They don't talk about the transactional portion of this, either up front for the consumer or behind the scenes with the integration.”

But there was a safety valve planned. All along, it was assumed that many people would opt for the “Learn” options and want to browse and explore plans before creating an account. That anonymous browsing functionality was turned off apparently just 10 days before launch.

In addition to cluing me in to the last-minute “no anonymous browsing” decision that greatly exacerbated the problems with the website design, Nancy added:

“Looking at the problem from the outside, it was apparent from the beginning that there were two potential areas of failure, both of which did fail, quite spectacularly. 

The first is that this was going to be an enormously difficult systems integration project. The system as conceived was going to have to integrate with/query a range of other systems, some government, some private, some state, none of which were designed to work with each other or to deliver this type of data in real time to external systems.

The second was that this was going to be a significant usability challenge. The user interface for this was going to be critical. You were going to be asking a huge range of people of all levels of computer literacy to go through a process that people are already primed to find bewildering and intimidating, as anyone who has ever received an Explanation of Benefits could tell you (as a friend of mine once said, the EoB is neither an explanation nor a benefit). This was going to have to be very, very easy to use, dummy proof, intuitive, lots of help along the way, and require no prior knowledge of how the system is supposed to work, how the insurance infrastructure works, terms of art, any of this. Particularly because the system was specifically intended to target people who do not have health insurance and have never interacted with the insurance system before or have glancing and traumatic experiences with the system.

It does seem clear that there was a dearth of people who understood the primacy of these challenges and/or who could speak truth to power about the need to prioritize both of these issues.

Somehow the people who knew how to prioritize this and how to get it right from the beginning, which included structuring the contracts, getting the right personnel, getting the right lines of authority set up, and in both cases, testing, testing, testing, were not high enough in the hierarchy.”

~ Nancy Seybold, Principal, Quartermark Consulting, LLC

If you haven't otherwise been able to register for Obamacare, you might try this website. 

If you just want information, go to this website:

http://rexharrisonshat.com/healthcare/

Click on “Apply Now”.

*****

Here’s our analysis of what went wrong and what should have happened:

Why the Healthcare.gov Insurance Exchange Bombed
Policy Makers Insisted on a Customer-Unfriendly Workflow
By Patricia B. Seybold, CEO and Sr. Consultant, Patricia Seybold Group, November 8, 2013

(Read the short sample and download the full article in PDF.)