When issues related to web design make the headlines, it’s a teaching moment that can help move the whole web design industry forward. In this case, the well-publicized problems with the Federal health exchange website strongly point out the importance of usability testing.
Not an optimization issue
This is a follow-up to my earlier post, Website Optimization and HealthCare.gov. That post was inspired by an article I read on Reuters. The Reuters article suggested that some of the problems on the Federal health insurance exchange website might be due to basic web design optimization issues. My review essentially concluded that Reuters was incorrect: that while the site was not well optimized, its problems were not related to optimization. In fact, I was unable to replicate the problem without actually going through the sign-up process. The major issues were on the back-end, where only site administrators can see the source code; not on the front-end, where any yokel can poke around and offer commentary.
Since I posted my original article, Congressional testimony has backed this up. Several public officials and private contractors have all testified that, as I suggested in my earlier post, most of the HealthCare.gov website’s issues are related to back-end integration. The initial deployment clearly suffered from project management issues that commonly plague software development: missed deadlines, and mid-level managers who don’t admit that their teams are not going to meet aggressive deadlines. The system included a number of components that weren’t completed until shortly before the final deadline. The components were integrated at the last minute, leaving no time for all-important usability testing.
Usability testing is essential
If your users can’t use your system, then you’ve got problems. And as all experienced developers know, usability testing is essential to discover whether or not a system works as expected.
A developer can build a system that appears to work perfectly when they test it themselves. But the developer knows how the system is supposed to work. Chances are, the developer is also probably using a blazing-fast computer and connecting over a lightning-speed network.
In the real world, users don’t have existing experience with your website. Users may be on legacy computer systems (like Windows XP running IE6… ouch!). Users may be visiting your website on mobile devices. Users may be accessing your web page over a rural network, where download speeds are still measured in kilobytes. A website that works great on a next-generation quad-core CPU connected via your corporate T1 line may be completely inaccessible by real prospects in the real world.
There’s also the problem of expectations. The developer who built a system knows what the system expects: how to get from one section to another, how to find certain pieces of information, and what inputs are required to move from one step to another. A typical user cannot be expected to know any of these things in advance. The user must be shown by the interface. A good interface is intuitive, and does not require a lot of thought or searching to be used successfully.
On the radio this morning I heard a HealthCare.gov user interviewed. She mentioned that one of the pages on the website has buttons that require a double-click. This is a terrible usability pattern, because it contradicts well-established use patterns. As everyone knows, you double-click the icons on your operating system’s graphical interface; but hypertext links (the ones on a website) and form submission buttons should only ever require a single click. Anyone who visited the page in question would expect the button to fire its onclick event after a single click. If the button failed to do so because it was waiting for a double click, then the user would assume that the system was broken.
And the fact is, if users can’t navigate the system, then it is broken.
System integration is complicated
Congressional testimony has made it clear that a button that expects a double-click is hardly the healthcare website’s biggest problem. The biggest problem is that different servers on the back-end of the system were having trouble talking to each other. This led to the error messages that have frustrated many users.
There is only one way to spot all the potential flaws in a system, and that is by watching typical end-users attempt to navigate the system. If a test subject is unable to complete a task, or if the system unexpectedly throws an exception when it receives a valid input, then the developer has spotted a bug that needs to be fixed.
The problem is that usability testing takes time, and costs money. That’s why it’s not practiced enough in the wide world of web design. Usability testing is instead offloaded onto real users, who don’t want to be a part of the testing process, and this can lead to a great deal of frustration, as we’ve all heard.
Unfortunately, I don’t have a screenshot of an error message to display here. My wife actually got one of the famous error messages, when she was trying to view information on CoverOregon.com on her mobile phone; and she took a screenshot for me, but then due to a miscommunication, it got deleted before I got a copy. Oh well. I tried to replicate the issue, but instead, all I got was a message saying that I qualify for a subsidy:
However, I note that CoverOregon does not offer online signup at this time. The homepage says you can call on the phone, fill out paperwork, or contact a consultant; but the actual online application is still “coming soon.” Sounds like they still have to complete some systems integration. Hopefully they will follow that up with some usability testing, before they open the system to the public.