Looks like the former executive for Microsoft Office, Kurt DelBene, will be the new leader of the Healthcare.gov. He’ll start work as a senior advisor to Kathleen Sebelius, managing the website and working toward improving its stability, interface, and security.
What we can learn from Healthcare.gov
The Healthcare.gov launch fiasco, subsequent Congressional hearings, daily bug updates, and Google engineer assistance has revealed just how poorly the United States government builds technology.
Two recent articles, one from Theverge.com and the second a NYTimes Op Ed, outline in beautiful simplicity, just how messed up the government’s approach to building technology is, from the presiding mentality to the archaic procurement process and beyond.
Everything That’s Wrong with Healthcare.gov
The HealthCare.gov launch did not go so well. Some people paid the website a visit only to be greeted by a blank screen. Others found error messages or talked to misleading call center reps or had their personal information compromised. The whole thing is borked, and everybody knows it. Read it on Gizmodo.
My continued fascination with Healthcare.gov
I really can’t wait to read the case study (novel?) on Healthcare.gov – the design, development, the rollout, the hearings, the politics, and beyond. I wonder what would have happened if we’d had the internet when Social Security was implemented.
Members of Congress continue to compare the shortcomings of the website to ecommerce giants Amazon, ProFlowers, and Kayak. I find it interesting how suddenly members of congress are ecommerce design, analyst, and development experts. (I know, I know, we’re all “users.”)
Security of the site was a topic in the hearings today, with lawmakers buzzing over the fact that the site security was not vetted enough (according to a warning memo). Ironically, Rep. Mike Rogers R-Michigan told Health and Human Services Secretary Kathleen Sebelius that, “Amazon.com would never do this.” Welllll…maybe not intentionally. Remember how awesomely bad Amazon.com and Apple cloud services were hacked last year?
Older articles published prior to the rollout show that Sebelius asked for patience, acknowledging there would probably be glitches in the coming days and weeks after the launch of the site. And that glitches are common, particularly in what the industry commonly refers to as public beta period. The key being that during a beta period, glitches and hiccups are identified and resolved as quickly as possible.
Sebelius also hoped that users would cut them some slack if things don’t go 100% smoothly, referencing unpopular updates to Apple products, “No one is calling for Apple to not sell devices for a year or to get out of the business because the whole thing is a failure. Everyone just assumes there’s a problem, they’ll fix it, let’s move on.”
It’s curiously amazing how consumers give tech companies leeway when using their products while they suffer through their growing pains. Apple’s iPhone wouldn’t let you copy and paste text for over a year after it went on sale. Windows 8 Start Button anyone? How quickly we forget.
Also, large technology companies like Twitter, Facebook, Amazon.com and Google are used to rolling out new features and fixes all the time from small, nimble deployment teams. Obviously, many of Healthcare.gov’s problems stem from the fact that there were 47 different contracts awarded; so exponentially multiply the anticipated number of code flaws per person on the team x the teams x the different contracts and companies involved. Oh yeah, add all the different databases that had to talk to each other.
Clay Johnson of the Department of Better Technology, a company that designs and builds software for the government, has been doing a great job of pointing out “you get what you pay for” when it comes to government procurement processes (my summary, his is more eloquent and evocative) and building this kind of site. If Amazon.com was the government ecommerce website selling everything under the sun, designed and built the same way as Healthcare.gov, launching the week before Christmas, how do you think it would go?
I was reading the most recent blog post on Healthcare.gov “Healthcare.gov: Improving the Account Registration Process” (yes, the site has a blog) which lists the biggest improvements the site has made to Account Registration since the site launched.
In combination, the following fixes are allowing users to successfully create an account and be able to continue through the application process. We can now process nearly 17,000 account registrants per hour – or five per second – with an error rate near zero:
- We replaced the virtual database with a high-capacity physical one, which allowed more efficient, effective processing and significantly reduced the error rates, or account registration failures;
- We’ve optimized software configurations to increase efficiency in system interactions;
- We added capacity by doubling the number of servers;
- We swapped out a directory component for another that can process more transactions simultaneously;
- We improved the efficiency of database look-ups through software changes;
- And we pushed through a patch release with four software fixes to address users that were having a hard time logging in to their accounts.
Unfortunately, the site crashed in the midst of hearings today, October 30, just when the congress person was pulling it up for reference. But if what they say holds true, 17,000 registrants an hour is no small feat.
Healthcare.gov, meet Congress
The anal probe of Healthcare.gov continues with agency representatives involved in developing and building the site appearing before a congressional hearing to answer questions about the glitches in performance and site requirements.
Some interesting UX revelations thus far:
Features are now basic expectations:
On two separate occasions different congressional representatives referred to online giant Amazon (and Ebay) stating: 1) Product comparison on Amazon is not as difficult as it is on Healthcare.gov, and 2) Amazon doesn’t crash the week before Christmas under the heavy load of users on the site.
1) Comparison capabilities. Amazon practically invented the ecommerce we know today. Once a feature, product comparison has now become a basic expectation of retail sites. Healthcare.gov has it, but it’s “difficult” to use comparatively. The UX side of me wants to know what portion of the experience made it “difficult to compare” insurance plans compared to the experience of comparing TVs on Amazon.com.
2) Obviously a working website is beyond a basic expectation. But in Healthcare.gov defense, Amazon didn’t launch less than 30 days ago to tens of thousands of users. And, despite ramping up, websites will get glitchy when there is heavy user traffic. Case in point: First day of the Nordstrom Anniversary Sale–trust me, they learned when no one could check out online a few years back. Never did go back and buy my shoes.
I think an even more logical comparison scenario would be to try merge Amazon, Ebay, Etsy, Macy’s, Zappos, Best Buy, and Apple into one ecommerce website and launch the day before Black Friday.
Last minute requirements/unnecessary hurdles:
Apparently, it was a “last-minute” requirement to make users create accounts prior to being able to browse insurance products. OMG. Why, why, why? That’s the equivalent of making users create an account to browse ANY ecommerce site. I would have punched the individual who mandated that. (Or the closest wall.) Can you imagine the shit-storm that created in the contractor ranks? The whole site was more or less bogged down due to concurrent registration. Fortunately, it’s been updated so that users can “window shop” insurance products without having to create an account first. Thank goodness.
Business as usual:
Congressional members seem to be fairly alarmed that one or more of the agency representatives are looking at the website problems as just another day in the realm of website launches of this nature (aggressive deadlines, last minute requirements, multiple vendors, numerous database reconciliations, millions of lines of code to test, etc).
In her prepared testimony, Cheryl Campbell (of CGI) said that “unfortunately, in systems this complex with so many concurrent users, it is not unusual to discover problems that need to be addressed once the software goes into a live production environment.”
“This is true regardless of the level of formal end-to-end performance testing — no amount of testing within reasonable time limits can adequately replicate a live environment of this nature,” she added.
Notably, many Republicans equated the problem-plagued website to a failure of the Affordable Care Act (aka Obamacare) itself. As Senator John Cornyn, R-Texas stated, “Obamacare is coming apart at the seams and it’s time to put this broken law to rest.”
As a UX professional, I will concede that a poor user experience can negatively affect brand perception in the mind of the user. But, as a UX professional that has seen the launch of many sites and interactive experiences, I confidently state there are always small glitches or scenarios that only reveal themselves, despite all the user flows, scenarios, Q/A and testing you do. Not to mention clients with last minute requests. (Anyone who says otherwise is lying.) Unfortunately for Healthcare.gov, this isn’t just any site. Not with people’s livelihood in play, as well as political theater and re-elections in the balance as well.
And while the site is getting “easier” to navigate and glitches are being addressed, politics are still involved. Which means the entire nation is now getting an education on how websites projects are often managed, designed, tested,and developed. For better or worse.
Healthcare.gov reminds us how not to build a website
3 years and an expected cost of half-a-trillion dollars ($638.81 million). And there you have it, Healthcare.gov. If ever there was a website that was going to be met with more scrutiny than an anal probe, this one is the front runner. Since the October 1 launch, the site has been fraught with issues resulting in a bug list that undoubtedly makes a Q/A want to curl up into the fetal position and wish they were considered “non-essential.”
Okay, I know. It’s a government site. That’s the first problem. According to dobt.com (Department of Better Technology) in a blog post “How Healtcare.gov Went Wrong“, there are a multitude of issues within the procurement process which have compounded the creation, development and launch of such a massive website. To begin with:
A High-Friction, High-Overhead contracting process: There was no competition for the Healthcare.gov contract. The Dept of Health and Human Services used an existing contract it already had with CGI Federal. (Which BTW, is the same company that built the portal for Massachusett’s “Romneycare”; you’d think they’d know what the hell they were doing already.) The contract was “greased”, meaning reduced friction. The normal procurement process would have taken about 18 mos, so in an effort to save time the government opted to take a contract they already had.
Requirements Written By People Who Don’t Understand Technology or Procurement: If you want (an IT project) to be a total disaster, let Congress design the requirements and set the deadlines. Enough said.
Building a Battleship like a Website: The process leans toward a write-down-all-the-requirements-then-build-to-those-requirements type of methodology–which makes sense if you’re building a space shuttle or a battleship. But this methodology doesn’t work when it comes to building a website, especially one over 3 years, where tools and techniques are bound to advance.
Lack of Pricing and Availability: In a functional, real-world marketplace, companies that do a good job at low cost will grow. Those that don’t will shrink. In the federal IT marketplace this isn’t how it works for two reasons: the federal government doesn’t know how much stuff should cost and doesn’t do a good job sharing performance-based information. The fed will track contractor performance based on misconduct, but not poor performance. And they don’t track pricing information.
Inappropriate relationships between Congress and Contractors: Contractors can lobby the federal government, and CGI Group, Inc lobbied the fed on the Affordable Care Act though there’s little data on what or why they lobbied. Still, it’s a question of ethics and the procurement process.
Pile all this on top of what appears to be a site that was never run through load testing, user testing, accessibility reviews, browser support and optimization, well then no wonder. People familiar with using the web expect things to work, and when they don’t, it damages the brand and perceived value of the website or experience they’re visiting. Unfortunately, this isn’t some bloated internal database that only government employees will have to suffer through. (The first page of the registration process (once you get to it) has 2,099 lines of HTML code, but it also calls 56 JavaScript files and 11 CSS files.)
This is a website For The People.
ittybittyusability 