HealthCare.gov’s Account Setup: 10 Broken Usability Guidelines

by Jennifer Cardello on October 27, 2013

Summary: HealthCare.gov’s account setup process is unnecessarily complex and may be contributing to backend technology failures.


The HealthCare.gov team has suffered what most web professionals fear most: launching a broken web application. This is particularly harrowing given the visibility of the website in question. The serious technical and data issues have been covered extensively in the media, so we won’t rehash those. Instead, in this article we focus on how to improve the account setup process. This is a user experience issue, but fixing it will also alleviate the site's capacity problems.

Account Set-up Usability is Mission Critical

Account setup is users’ first taste of a service. A suboptimal account setup can spawn 3 problems:

  1. Increased service cost: When people can’t self-service online and you have no competitors, they call you. Call-center interaction is more expensive than web self-service. In 2008, Forrester estimated call-center calls to cost $5.50 per call versus 10 cents for a user who self-services online.
  2. Increased cognitive strain: The instructions for creating usernames and password in this flow (which we address further along in this article) require a great deal of concentration, and if users don’t understand the instructions, they will need to keep creating usernames and passwords until they are accepted.
  3. Halo Effect: Account setup is the first in a series of web-based interactions that users will need to conduct on HealthCare.gov. A poor experience with this first step will impact how people feel not only about subsequent interactions with the site, but how they feel about the service in general and the Affordable Care Act as a whole.

Account Setup Usability Guidelines

NN/g has developed thousands of usability guidelines for creating useful and usable interfaces. The following are just 10 of those guidelines as they pertain to account setup.

1. Allow users to see the product/information before registering.

According to an article on Reuters.com (U.S. Contractors shift blame for HealthCare.gov problem), when HealthCare.gov launched, prospective enrollees had to register before they could view the plans. This problem has been somewhat addressed later by adding a See Plans Now button on the homepage, an article about viewing health plans, and an externally hosted calculator. Through years of usability testing, we have observed that forcing users to register before seeing their options is never a good experience. When information is not provided upfront, users tend to move into a defensive mode. They don’t know what to expect and whether what awaits them after registering is worth the effort of creating an account. This is similar to requiring prospects to register before they can check out on e-commerce sites and is an example of the law of reciprocity applied to the web. (The law of reciprocity says that people are more likely to respond positively to a request such as filling in a form if they are given something — for instance, information — in advance.)

Additionally, this lack of information and required registration could have contributed significantly to system failures because account setup requires more processing power (i.e., server calls, database calls) than simple browsing of the site to gather information. Forcing people to create an account before being able to view options generates a tremendous one-time burden on your system.

2. Keep calls to action (CTAs) and other pertinent information above the fold.

There are certainly examples of sites that have drastically improved conversion rates when they moved CTAs below the fold — and preceded the CTAs with persuasive, meaningful content and useful features. However, this isn’t the case with HealthCare.gov. People who are coming to this site want insurance — they don’t need to be sold on it. What is pushing the CTAs down the page is a big hero image that does not contain useful information.

However, even more problematic is that, depending on the resolution with which users view this page, it may not be clear that there is any content below the virtual page fold, so they may not scroll. Users do scroll, but only if it’s obvious that there is content to be had below the fold.

screenshot of Get Insurance page form Healthcare.gov

The Get Insurance page is the 2nd page into the site, once the user has clicked the Apply Online button on the homepage. The dotted line indicates the virtual fold at 1366x768 resolution which is now the most populous desktop resolution as desktop screens are getting bigger.

Above, we have illustrated where the virtual fold occurs at a resolution of 1366x768. As you can see, it is not obvious that there is content below the fold. Instead, users may believe that their only choices are the 2 buttons overlaying the image (Individuals & Families, Small Business Owners) and the 4 global navigation choices (Learn, Get Insurance, Log In, Español, and Help). Many sites do attempt to funnel users into subsites targeted to individual market segments, so users can quite reasonably assume that this site takes a similar approach. The key rule governing the web user experience is that users spend most of their time on other sites and thus have formed their expectations for your site based on the cumulative learnings from common design patterns on these other sites.

When users simultaneously encounter an illusion of completeness and a seemingly sensible set of options above the fold, they can be excused for not looking below the fold. On the other hand, the designers cannot be forgiven for having created this illusion of completeness, since this is one of the most well-documented problems in web usability.

Recommendation:
Place the Choose Your State and Apply buttons up much higher on the page. To make space for them, either replace the hero image or position the buttons alongside the image (below marketing content or replacing it).

3. Prepare users.

A process-like, iconic graphic appears once the user has selected their state and clicked the Apply Now button. Unfortunately, it doesn’t explain the account setup process at all.

The Get Started page is the 3rd into the site, once the user has selected their state and clicked the Apply Online button on the homepage. The graphic at the top of the page does not explain the process. While the second circle might look like a computer, we challenge anybody to guess the meaning of the illustration in first circle. The smiling women on the previous page (in the hero image) are useless filler, but this illustration is downright harmful, because it primes users to expect a mysterious and difficult process.

Note that the previous page in the process, Get Insurance, also contains a high-level overview of the entire process from account setup to enrollment. Unfortunately, most people won’t see it because it is placed below the call to action buttons.

Recommendation:
Replace the graphic with the information that answers the following questions:

  • How much time will this take?
  • Do I need any special information ready before I start?
  • Is this part of a larger process? The Marketplace application is mentioned — where does that fit into the big picture?

4. Number the steps.

Most users will not recognize the 3 dots as a progress meter because:

  • They are located in the lower left corner (progress meters are typically across the top).
  • They are unfamiliar to many people who don’t use Apple products.

Dots as a progress meter are nonstandard in most linear progressions. Numbered steps or completion meters are more recognizable.

Recommendation:

  • Replace the dots with numbered steps or a percentage-complete progress bar.
  • Locate the progress meter at the top of the forms.

5. Use email address as username.

The username creation criteria are incredibly confusing:

  • Between 6-74 characters
  • Must contain a lowercase OR capital letter
  • Must contain a number OR a symbol (acceptable symbols: _.@/-)

Complex username and password schemes require more concentration than most people are willing to commit to this seemingly simple process.

We assumed that an email address would meet the criteria, but it doesn’t.

Many people do not read instructions. Complex requirements will generate more errors, cause user frustration, and increase system load.

Additionally, the error message does not indicate what is wrong with the username; which of the criteria does it not fulfill?

There are 6 benefits to using email address for username:

  1. Email addresses are easier for users to remember.
  2. The email address is a unique identifier.
  3. It’s standard practice on millions of other websites.
  4. It reduces error rates because people don’t have to parse the overly complicated criteria.
  5. It simplifies the process by eliminating the creation of a unique username.
  6. And it could reduce the number of screens in this account set up process by merging the screen that currently collects email with the screen that currently asks the user to set a username and password.

Recommendation:
Work with your security experts to determine why email addresses cannot serve as usernames.  Then determine if the potential security concerns can be addressed.

6. Simplify password requirements.

As with the username, password criteria are incredibly confusing:

  • Between 8-20 characters
  • Must contain a lower case letter, an upper case letter AND 1 number
  • Must be different than your past 6 passwords (What? Where? In all the web?)
  • Cannot contain your username
  • Cannot contain these symbols: +?<>()’”/\&

(Note that the slash character is allowed in usernames but prohibited in passwords. While this is a smaller problem, it adds to the confusion. Better to either avoid listing these cryptic characters or have the same list for both pieces of user input.)

Complex password schemes often create a flurry of errors and, worse, high abandonment rates.

What exactly is the reason for each of these requirements? For example, “It must be different than your past 6 passwords”: Is this instruction necessary here, when users are first creating a password? We typically only see this in Intranet password-change instructions. And what about the specific disallowed symbols: Is there something about them that will conflict with backend code? Why don’t we see these restrictions on other websites?

Recommendation:

Work with your security experts to determine what drives each of these requirements and then determine if these are reasonable. It’s important to be persistent to get to the bottom of this complexity in order to figure out how to eliminate it.

7. Provide specific and actionable error messages.

Errors are a fact of web-life. Designers and developers are working tirelessly to prevent them, but when they can’t, the next best thing is an easy recovery. But it’s difficult to recover from an error when the cause of the error is not identified.

For example, we had cut and pasted an email address into the email field and received a “This is not a valid Email address” error.

The error received when the inserted email address includes an empty space at the end, does not point out the specific issue.

Was this email invalid because it had the term “testignore” in it?  No, it turns out that we had accidentally added an empty space at the end of the address when cutting and pasting it. (Something that's invisible and thus won't be caught by most users.) Once the space was deleted, the email address was approved.

Recommendation:
For email and password errors, most users won’t or can’t troubleshoot. Make error messages specific, or, at least, include a list of potential causes so that users can attempt to identify the issue.

8. Display passwords as users type them.

As users type their new password into the 2 fields (Password and Confirm Password fields), the letters do not appear (not even for a split second, as with some applications). Instead, they just see dots, which can cause some usability issues.

Users cannot see the password that they are creating.

Masking passwords actually lowers security. As Jakob Nielsen points out in his article on this subject, users make more errors or use overly simple passwords to reduce the chance of making an error when they cannot see the text that they input.

Recommendation:

  • Display passwords by default.
  • If account security is of considerable concern, offer a checkbox to mask the password.

9. Remove unnecessary steps

Every step in a process is one more chance for a user to drop out of the online application and pick up the phone. On many sites, users don’t have to set security questions on initial signup; instead, they do it when they first log in. If the site relies on security questions for username and/or password recovery, it may need to include this step at signup. We could not determine if that was the case for HealthCare.gov, because password and username recovery were not working.

Including the security question setup within the account setup process increases complexity and increases the likelihood of abandonment. On many sites, this step occurs during the user’s first secure visit.

Recommendation:
If possible, remove the security questions from the initial account setup. Instead, ask people to answer these the first time they log in.

10. Simplify instructions and content for low-literacy readers.

The HealthCare.gov site adheres to the Federal Plain Language Guidelines as indicated by a link in the footer of the site. We measured the grade level of instructions and articles on the site (using the Flesch-Kincaid Readability Test), and found that it is generally written at a 9th-grade reading level. Still, the audience for this service is extremely broad and is likely to contain a higher proportion of low-literacy readers. Our research indicates that in order to reach people with particularly low literacy levels, it’s better to write 6th grade copy.

The more confident users feel in having understood the instructions and the concepts behind the site, the more they will persevere through slight difficulties with the interaction. Conversely, if users are confused to begin with, they'll get even more confused if the site doesn't work like they expect. A growing feeling of defeat will make people abandon the site.

Recommendation:
While the very best would be to simplify the underlying concepts, as a shorter-term fix write even simpler instructions and explanations.

Conclusion

Of all the things that, reportedly, are not working properly on HealthCare.gov, tweaking to meet these usability guidelines is low-hanging fruit that can have a significant impact on costs. The usability fixes will even lighten the load on the over-stressed backend, because a better UX will prevent users from attempting the same actions over and over again. If people cannot sign up online, they will call, and then the enrollment costs will increase exponentially. If users get confused with something as simple as online signup, they’ll be wary of every other online interaction that the organization offers.


Share this article: Twitter | LinkedIn | Google+ | Email