During the Affordable Care Act’s open enrollment last year, more than 7.5 million eligibility applications, encompassing over 11 million Americans seeking health coverage, were submitted on HealthCare.gov. After applying, people are informed about what kind of health coverage they are eligible for and how much financial assistance they qualify for. Around 80% of Americans who applied for health coverage on HealthCare.gov were eligible for some form of financial assistance. When the site originally launched in 2013, it was a different story. Many people struggled to get through the eligibility application and a significant percentage weren’t making it the whole way through. In partnership with the Centers for Medicare and Medicaid Services, Nava Public Benefit Corporation designed and built a new eligibility application, and enrolled people at a 50 percent higher rate than the original application.
Building on that work, our design team reimagined the end-to-end help experience, and established help content design patterns for the entire site. The primary goal: to respectfully and clearly guide people through what can oftentimes be a deeply personal process, one that will determine how they care for themselves and their family.
For this work, we defined “help content” as any message component whose purpose was to further educate the applicant about such things as:
the website itself, policies and regulations
terminology
guidance
frequently asked questions
In this post, I’ll talk about the approach we took to audit the existing experience of seeking help and guidance on HealthCare.gov, where we identified the various types of help content and the patterns that were being used to display that content. Then I’ll discuss the help patterns that we began to implement.
Auditing the existing experience
A HealthCare.gov applicant’s journey involves filling out an eligibility application for their household, viewing their household’s eligibility results, comparison shopping health plans, and enrolling in a plan. There are multiple contractors working on different areas of this experience, and as a result, help content (amongst other things) has been inconsistent. As the first step in our work to more consistently present help content, Nava’s design team did a complete audit of the existing experience.
Goals of the audit:
Provide a shared baseline understanding of the current state of help on HealthCare.gov.
Capture a comprehensive list of use cases for various help patterns.
Evaluate different methods of providing help based on discoverability (and other heuristic criteria listed below).
Serve as an input into the creation of help content design patterns, to be used throughout the entire user experience.
To accomplish the above goals in our audit, the team took the following approach:
Stepped through each user flow, accounting for various household scenarios (e.g. a single member household versus a multi-member tax-filing household).
Captured screenshots of help patterns surfaced at each step.
Documented each help pattern while evaluating: discoverability, usability and accessibility, visual design and consistency, voice and tone.
Synthesized observations into “How might we” statements to inform design explorations.
Types of help content
After going through the entire user experience multiple times, we came away with a comprehensive list of seven types of help content that we would need to account for in our designs. These included:
Definitions — Definitions explain what a particular term means. For example: “What is a tax dependent?”
Justifications — Justifications explain why a question or piece of information is being asked for. For example: “Why is the government asking about my race and ethnicity?”
Consequences — Consequential help content explains how the applicant will be impacted or what happens when a particular condition is met. For example: “What happens if I answer ‘Yes’ to this question?”
Answer guidance — Answer guidance explains when to select a particular answer, what type of info to enter, or where to get the info from. For example: “Where can I find my I-551 number?”
Process guidance — Process guidance explains how to use the site or what to do next. For example: “I enrolled in a plan, now what do I do?”
FAQs — FAQs are help content where the most commonly asked questions are highlighted and are answered inline or through a link to another page. One common example: “How do I submit verification documents?”
Help routing — Help routing content directs an applicant to more help. For example: “How can I learn more about deductions?”
Types of UI patterns
A very small subset of the existing patterns we identified in our audit.
While we categorized the existing types of help content, we also documented the various patterns that were being used throughout the current experience. What we came away with was a picture showing a fragmented and inconsistent design language for displaying help content, and a clear understanding that there was room to improve the usability, accessibility, and consistency of help patterns.
This table shows where each help pattern was used in the user flow.
In the current experience, eight different patterns were being used in different parts of the flow for the same types and shapes of help content. The table above shows the breakdown of patterns and the various sections they were used in.
What we learned
After doing the audit, we came away with the following takeaways, framed as open questions to be addressed in the exploration phase we were about to enter:
How might we minimize the number of ways and effort to seek help?
How might we better anticipate and answer applicants’ most common questions based on their recent actions, current personal situation, or their location within the application?
How might we present the minimum information required for the task at hand, while still providing access to help content when the applicant wants it?
Bites, Snacks, and Meals of help content
Help content has different shapes, purposes, and relevancies. We understood going in that there isn’t a one-size-fits-all solution for help content, however we also believed we could reduce the number of existing patterns to create a more consistent and predictable experience. Through rounds of exploration, the design team established three different categories of patterns to accommodate the various shapes of content. Through conversations with our government partners and other teams, we found “meal size” to be the easiest way to describe these categories.
Bites — One to two succinct sentences
Snacks — One to two paragraphs
Meals — Longer form content
Bites of content
One of the help content principles the team established early in the process was: If the content is important for the majority of applicants, put it on the screen. In practice, this content typically takes the form of a page lead, field label, or hint text.
Page lead
This is an example of a page lead.
A page lead is a short block of text following the page’s title. Not every page needs one, but it can be useful when the intent of the page’s questions or functionality might need explanation. The page lead should provide any necessary context, set the applicant’s expectations, and help frame things so the applicant knows how and why they’re answering the questions that follow it.
Field labels and hint text
This is an example of a field label and associated hint text.
Within the application, we aimed for clear and succinct field labels, keeping the field label text short, direct, and in sentence case, consistently placed above the associated field(s).
Hint text, placed below the field label, is used to provide additional help content, and is read aloud by a screen reader directly after the field label. This text provides details that can help a majority of applicants enter an accurate answer. This includes guidance, definitions, clarifications, and vital security/privacy concerns to overcome.
18F’s content guidance to “Provide enough context” is particularly relevant for hint text and page leads:
Understanding people’s possible attitudes toward the requests you’re making can help you determine where to provide contextual information and how much to provide. If you’ll be requesting Social Security numbers, financial data, or personal medical information, you may want to share why you need this information and explain the safeguards you’ll be taking to protect it. Providing this context can help users feel more at ease and create a more satisfying interaction.
Snacks of content
In some cases, content is relevant to only a small subset of people, or the amount of content would add too much to the page’s cognitive load. We still want to provide this help when it’s relevant, but we also don’t want it to be a distraction. To support this, we explored a few patterns that would disclose the content upon request or when it’s relevant, without taking a person away from their primary task.
Help text disclosure
This is an example of a help text disclosure pattern.
The help text disclosure pattern includes a short summary link that expands into more detailed help when an applicant clicks it. The help text is displayed inline, within the context of the current page, keeping the applicant within their current flow and allowing them to reference the associated form field(s) and neighboring content. This pattern also benefits from being a native HTML 5.1 element.
Consequential callout
This is an example of a consequential callout.
A consequential callout provides follow-up help content after an applicant has performed an interaction, such as selecting a checkbox. In eligibility applications, consequences for answering a question a certain way can be quite severe. With that in mind, the styling of the callouts vary depending on the severity of the consequence. For example, if an applicant answered “No” to “Do you want to see if you qualify for savings on coverage?”, we show a warning callout indicating that selecting “No” means they’ll pay the full price for their health plan.
Meals of content
Though the design and content team always aims for brevity, there are some complex topics that prove difficult to summarize on a page. For these cases, where the content surpasses 600 characters, we wanted an interaction pattern that would allow the applicant to quickly get the answer they’re looking for, and intuitively return to where they left off.
This is an example of a help drawer on TurboTax.
The pattern we landed on is a “help drawer”, similar to the one demonstrated above. When a person interacts with a help drawer link, the drawer expands on the right side of the page on desktop, or overlaid full screen on mobile. The drawer provides a space for longer form content, is treated as a last resort for providing help content, and should still be as brief as possible. Accordions can be used within the help drawer to aid in scannability and reduce the complexity of the content even further.
Global help
The patterns mentioned above account for help content that is meant for a wide range of possible scenarios. Sometimes though, the content still might not make sense to someone or it doesn’t match their particular circumstance. People are justifiably nervous when entering personal info into a lengthy online form. Some are more comfortable connecting with a representative for reassurance or guidance.
This is an example of a persistent global help button on Facebook. The help icon provides a consistent place to seek help.
To help people find the help or reassurance they need, we proposed one of the most well established patterns out there — keep a persistent help button in the global navigation, similar to the Facebook example above. Interacting with the button provides a person with contextual help related to the current page, as well as global help info like the call center’s phone number and local help resources.
Evolving our help patterns
We’re excited to continue researching and validating these help patterns. We’ve started incorporating them into other initiatives, like our work with state governments building faster, easier, and less expensive ways for people to access safety net programs. If you’re working on similar problems, please write about them, contribute, and share! We’d love to learn from your experiences as well.
Resources that helped us:
Web Form Design: Filling in the Blanks, by Luke Wroblewski
Designing good questions — and the related discussion — by GOV.UK
Special thanks to Jodi Leo, Zoe Blumenfeld, and the entire design team (Olivia Cheng , Susan Lin , and Kelli Ho) for helping put this together, and to the many dedicated civil servants who collaborated with us to improve the user experience over many years.
Written by
UX Designer, Frontend Developer
