A Cautionary Tale: Lessons from Healthcare.gov On Launching A Website

A Cautionary Tale: Lessons from Healthcare.gov On Launching A Website

Anytime you shell out more than $600 million on website development I would imagine you would be expecting a little more than a meltdown in the press. Except that is exactly what has happened since Healthcare.gov was launched. It’s been met with criticism from the start, but with a high price tag, high expectations, and a website that is not living up to its publicity that is exactly what you can expect.

It’s a position that no one wants to be in: you pour money into a website, ratchet up enthusiasm, publicize the launch date — and nothing works as it should. Granted, a multi-million dollar software and website development project is not as simple as setting up a WordPress site, or launching a blog for your business, but the steps to take prior to launch are one and the same.

I’ve compiled the lessons learned from the Healthcare.gov fiasco and distilled them into problem areas that can plague any project, as well as, actionable solutions that will help you prevent these errors when launching a new product, software, or website.

First, we’ll take a look at what happened. This will shed light on the mistakes that ended up causing site outages, poor user experience, and bad press.

Next, we’ll move to the solution, which will tell you exactly how you should be approaching these issues.

And we’re off…

1) Make sure your server can handle expected traffic

What happened: Website taken offline after launch; not able to handle traffic.

The solution: Common sense? I hate to use sarcasm, but the reality is that this was a terrible oversight, one that had been outlined prior to launch. According to the documents released by MSNBC, people were quite aware of this problem, which makes it hard to understand why it was not addressed.

From the document (look towards the bottom):

  • Capacity: 1,100
  • Expected: 55,000
  • Actual: 250,000

The expected visitor count on launch day was 55,000 — yet the system could only handle 1,100 visitors at once. When launch day came though, a whopping 250,000 showed up. This consumed resources so quickly it had the same effect as a DDoS attack. The site quickly went offline.

Healthcare.gov Expected Visitors to Actual

It’s always important to overestimate the resources you need when launching your website, more so if you’ve put a lot of investment into marketing and PR prior to launch. A lot of the bad publicity could have been avoided if this rule was followed. Most of the arguments now are centered around the website. People were sold high expectations, and the delivery sucked. It will be hard for Healthcare.gov to recover from all the negative press, but at the end of the day it’s still a government website. Chances are it will recover because it’s mandated. If this was a startup vying for customers and good press they would have missed their chance.

2) ALWAYS test prior to launch… and then test some more

What happened: Countless problems with accessing the site and signing up.

The solution: I cannot underscore how difficult a project this had to have been. It’s a massive undertaking. The design isn’t really where the problems come in — it’s how the site operates. Healthcare.gov was riddled with errors causing people not to be able to sign up for healthcare. The way that this could have been sidestepped is pretty basic: test.

Anytime you are launching a web property; whether a site, software, or app you have to make sure that everything is working as it should. The more visitors you expect to visit your site, the more extensive your testing should be.

Some key areas to test:

  • Does the signup/subscribe/checkout processes work correctly?
  • Can visitors navigate the site easily?
  • Are all the links working correctly?
  • Have we checked all content for typos or errors?
  • Do we have a help desk or support system? Is it working?
  • Do all forms on the site work? Do they display entry errors properly?
  • Is all of the content being loaded securely?
  • Are all of the database functions working as they should?

As you can see there are quite a bit of things you should be looking at. You need to approach the site as a visitor would, not like the person who developed it. This is why third-party testing can be a good idea. Often times, other people will uncover errors you haven’t and you’ll get an idea how random people will navigate the site.

3) User experience is never an afterthought

What happened: People became frustrated with the difficulty in signing up for plans and/or accessing the site.

The solution: Much of this was covered in the last section: to avoid the pitfall of poor user experience you must test your website before launch. It does extend a bit beyond that though. It involves user experience. A great design is key, but never sacrifice usability for a pretty look. You want your website to do what it is intended to do. If your goal is increasing sales, it should be easy for your visitors to purchase products. The same goes for subscribers. You want a big mailing list? Make it easy for your visitors to subscribe. You want people to sign up for health care coverage? Make the process seamless.

Final Thoughts

I can think of a long list of startups that could have pulled this off under budget and with better results.

What’s your take?

About the Author

Leave a Reply