3 Non-Technical Solutions to Obamacare’s Biggest Website Problems
More than two weeks after its debut, healthcare.gov continues to cause frustration for its users and potentially career-ending criticism of its leaders. In fact, members of congress have started calling for the resignation of Kathleen Sebelius, Secretary of Health and Human Services, and there are now two House committees investigating the website.
While many of the problems are technical in nature, such as lack of optimization and challenges integrating with legacy systems, much of the failure and subsequent negative press could have been avoided through better communication and user experience design. A few days after healthcare.gov was launched, Forbes reported that only 1% of site visitors ended up enrolling. I see that number as not only a sign of performance failure, but also a sign that they failed to accurately identify and accommodate use cases beyond “Enroll in the Exchange.” The following are some usability suggestions that don’t require monster servers or technical genius to implement. (Ms. Sebelius, feel free to bring these ideas to your web development team and present them as your own. You’ve had a rough week.)
1. Filter out the users who don’t need to be there.
Healthcare.gov is the online Federal exchange for Obamacare. However, some states have their own exchange. In New York, for example, you can visit nystateofhealth.ny.gov. As soon as there was any indication that the federal site was overwhelmed with traffic, options to funnel people to their state exchanges should have been put in place to reduce the load. The nice thing about a simple “What state are you browsing from?” filter is that it can direct some users to other sites without hitting the healthcare.gov servers again.
2. Allow and encourage users to browse for plans anonymously.
Server optimization is an art and a science, and I don’t doubt that the people responsible for optimizing performance on healthcare.gov are among the top in the field. The expected peak of simultaneous sign-ups was 60,000, but the actual peak was as high as 250,000. The original assumption of 60,000 was based on a workflow where users would create an account when they were ready to buy, which is typical of most eCommerce websites. However, a late decision was made to require users to log in before browsing for plans, because they didn’t want to give people sticker-shock by showing plan pricing without factoring in the subsidies an individual might be eligible for. You can only give someone an accurate quote if you already have their information.
There’s a simple solution to this that auto-dealers and insurance companies employ constantly: the “as low as” price tag. For anonymous users, show not just the raw cost of a plan, but the lowest cost or perhaps low-average cost of a plan, and THEN prompt people to create an account to get their specific rate. This would reduce the number of simultaneous account creations two ways: First, fewer people would need to sign up for an account. Second, since account creation options are presented over time throughout the browsing process and not as the sole gateway to the rest of the site, the chances of so many accounts being created at the exact same moment are greatly reduced.
3. Foster transparency AND accessibility.
When confronted with criticism that healthcare.gov “hides the price tag” of plans behind a log in, administration officials point out that all information is available in its raw form on data.healthcare.gov. There are two problems with this argument. First, who would know that? There are two major calls to action on the healthcare.gov homepage, Apply Now and Start Here, both of which start by asking you for information. There is not a single link to data.healthcare.gov from the main healthcare.gov homepage. (I checked the HTML code to verify this.)
Second, once you do find out about the site (likely via an administration official defending himself against accusations of lack of transparency) you visit and quickly realize it’s about the least user-friendly thing you’ve ever seen. There are tons of “datasets,” huge spreadsheets with file descriptions like, “This CSV contains the Table C data contained in each submitted Part 1 Rate Summary Form.” I almost got excited when I saw that on the left side bar, you could view Charts, Maps, and Calendars. However, upon clicking on each of them, it turns out there are no charts, no maps, and no calendars. Basically, the site is useless for the average person who just wants to know what their options are.
There is a technique called “secrecy via obfuscation,” where sensitive information is weakly protected by being buried within mounds of useless or irrelevant data. That’s likely not the intention of data.healthcare.gov, but to Obama’s critics and political opponents, it might as well be. Transparency isn’t achieved by simply making information available. It has to be targeted, clear, and concise. This is an issue of content strategy and usability, not technology.
I don’t envy the folks tasked with cleaning up this mess, but I hope that in the midst of network optimization and system integration, some attention is paid to these user experience issues. After all, the whole point of Obamacare and healthcare.gov is to help folks who’ve already been failed by a complex, incomprehensible healthcare system, right?