Don’t Let Your Website Bomb Like the Obamacare Healthcare.gov

What were the problems with the Healthcare.gov launches?

By now, everyone is familiar with the problem-ridden launch of the various Obamacare/healthcare.gov websites.  So what happened?  And why was the launch so problematic?  The Obamacare website launch problems boil down to the following:

Data center shutdown-  The online insurance marketplaces lost connection to its datacenter and officials are unsure how long it will take to fix the problem.  Data centers are vital to the functionality of  a site.  Without a reliable connection and secure hosting, many applications could fall through the cracks.

Frequent crashes– Crashes have been the most visible sign of the websites’ failures. When individuals visit healthcare.gov, or a related site, they are redirected to a page not found screen, a request to wait, or requests time out.  These errors both discourage users and can harm your relationship with your users.

Accounts in purgatory–  Accounts in purgatory are more annoying than they are dangerous.   Essentially, many accounts were not properly authenticated due to programming glitches that didn’t allow information to flow between various system components.

Human Error– There clearly have been some serious problems in the conceptualization, design and execution of the healthcare.gov websites.  These errors cannot always be avoided, but they should be acknowledged and treated before the launch of a website.

How can I avoid similar problems?

Unit Testing– Unit testing is a development practice that allows for manageable and scalable testability.  When designing a website you’ll first want to make sure that each part of the website/program works properly.  Next make sure they work as a whole- all websites are composed of many parts or functions that will need to work together.

Quality Assurance Measures/Metrics-  Bug Tracking, pre-release testing and repeat testing are all essential aspects of web programming.    Essentially, every web programmer should know their sites’ weaknesses and take steps to remedy them.  Continue testing your site until it works perfectly every time.

End to End testing-  Test your systems’ flow for weaknesses.  Make sure they work as expected, and that the right information is passed between the various components that result in the expected outcome.  Tests should be done in a real-world scenario (i.e. use your website as a visitor or potential client would use your website. Anticipate their needs, questions and pathways). Evaluate your results using the following questions: How hard is it to use the system? Can users even complete their desired goals? Does the system bottleneck in any particular places?

Stress Testing- First, simulate the anticipated load and measure how it is handled by the current system.   Stress can also test how your site will fare under extreme conditions.  These conditions generally include excessive web traffic, disk failures, unexpected outages etc.  The purpose of such a test is to find bugs before they can cause problems.

Find out how much load other dependent systems will handle.  Will the delay or disruption in their service effect my systems functionality, user-friendliness, and/or performance? (Then make changes to mitigate any impedance).

Better Planning- Ask yourself the following questions: Are my system requirements technically feasible? Don’t ask your developer to do the impossible! Consult with a specialist to figure out the best way to design and program your website.  And do we have the labor force, time and money to execute the project successfully? As system complexity goes up, development cost goes up both in time and money.

 

What should every business learn from the Healthcare.gov launch problems?

The Healthcare.gov website launches failed because they didn’t take the time to properly test and assess their systems.  The neglect caused numerous glitches that resulted in overwhelmingly negative user experiences.

Remember that you must carefully plan your website and account for significant testing.  It’s never worth sacrificing skilled labor for a cheaper budget (if you must sacrifice labor costs you’ll have to allow for longer development time).

Take the time to do things right because bad user experience = bad publicity.

Skip to content