In my column today, I argue that the Healthcare.gov disaster has its roots in the government-contracting system, where big projects that go past deadline and over budget is standard operating procedure. There is one particular design flaw, however, that I didn't get a chance to discuss there but is worth noting. My guess is that it wasn't given all that much thought, or at the very least, somebody had what sounded like a good reason at the time to do it the way they did. But the result was that the administration needlessly multiplied the headaches it would have with the rollout and made everyone's experience significantly worse, and it didn't have to be that way.
Before I tell you what it is (the suspense is killing you, I know), let's stipulate that Healthcare.gov did indeed present an extremely complex challenge, much more so than just creating an ordinary website. That's because it isn't a closed loop, but rather needs to communicate in real time with a bunch of outside systems, including insurance companies, a variety of federal agencies, and vendors like Equifax. When you use it you aren't just viewing information, you're engaging in a transactional process, with information going in many directions and things changing based on each new piece of information. The problems all have their origins in that back-end complexity.
But the single biggest mistake the designers made in constructing the site was allowing that back-end complexity to grind the website's front end to a halt, by not allowing visitors to browse health plans and get information without first going through a registration process. It's almost impossible to overstate how consequential this decision was. Requiring registration in order to get information put up a roadblock in front of every visitor and left them with no available detours to travel when things went wrong. As one tech-industry veteran told me, "It's like taking ten lanes of traffic and pushing them into one lane." With that one lane at a near-standstill, no one could move. That means that no matter whether you wanted to sign up that day or you just wanted to take a look around, you'd be stymied and come away thinking the whole thing was a mess. It was as though they only designed the site as a place to sign up for coverage, without realizing that people would use it the way they use any similar site: to browse around, check things out, maybe buy something, maybe not.
Even if all the back-end problems had been exactly the same, had it been possible to wander around the site without registering, most of the people who visited in those first days would have had a perfectly pleasant experience, since most were probably not intending to make their final insurance decision on their first (or even second or third) visits. And you wouldn't have had all those TV news stories in which a reporter got on his or her computer and tried unsuccessfully to access the site, with the camera zooming in on the error page. Like this one, from NBC:
Or this one, from ABC:
Or this one, from CBS:
Images like those have been featured in about a zillion news stories. After the site had been up for a few weeks, they got around to changing it so you can now browse without registering. But by then the damage had been done. This should serve as a reminder that it's useful when designing something like this to ask, "What if something goes wrong?" Then you can design things so that one problem, or even a bunch of problems, don't torpedo the whole thing. It sure looks like nobody asked that question.
