Designing Human-Centered and Accessible Digital Services for HHS

People do not experience an HHS program as an org chart or a software application. They experience a sequence of questions, documents, decisions, phone calls, websites, appointments, and waiting.

Human-centered design starts with that whole journey. It asks what a person is trying to accomplish, what they know at each step, what barriers they face, and how the service behaves when their situation does not match the happy path.

Accessibility is inseparable from this work. A service that excludes people with disabilities or fails under assistive technology is not complete, even if its primary interface looks polished.

Health and human-services interactions often happen under stress. A person may be sick, caring for a family member, using a shared phone, working with limited connectivity, reading in a second language, or trying to meet a deadline.

Research should include people who reflect the service population, especially those likely to encounter barriers. Frontline employees, navigators, call-center staff, and community partners can reveal workarounds and policy friction that analytics alone will not explain.

• Observe complete tasks rather than asking only about preferences.
• Recruit across disability, language, age, geography, device, and digital-confidence dimensions.
• Include people who started but could not complete the service.
• Protect privacy and minimize collection during research.
• Translate findings into testable service and policy hypotheses.

People should be able to tell whether a service applies to them, what they need, how long it may take, what happens next, and where to get help. Clear structure reduces anxiety and prevents avoidable contacts.

Plain language is not simply shorter text. It organizes information around the reader’s task, uses familiar words, explains necessary terms, and places the most important information where it is needed.

Digital.gov guidance emphasizes designing for understanding. Headings, lists, white space, examples, and meaningful links make content easier to scan and act on—especially on small screens or in stressful moments.

Section 508 and related accessibility standards provide an essential baseline for federal digital services. Meeting that baseline requires more than running an automated scanner at the end of development.

The U.S. Web Design System offers accessible patterns and components, but it correctly notes that using accessible components does not guarantee an accessible implementation. Content, configuration, interaction design, and custom code can all introduce barriers.

• Use semantic structure, visible focus, logical keyboard order, and sufficient contrast.
• Provide labels, instructions, errors, and status updates that assistive technology can interpret.
• Caption media and provide appropriate text alternatives.
• Avoid time limits where possible and provide accessible extensions where needed.
• Test with automated tools, manual review, keyboards, screen readers, zoom, and real users.

Many public services become hardest precisely when something goes wrong. A document is rejected, a name does not match, an account is locked, eligibility is unclear, or a submission arrives after a deadline.

Error messages should explain what happened, preserve valid work, point to the problem, and offer a practical next step. Users should not need to understand the agency’s internal structure to recover.

Assisted and offline channels must connect to the same service. A call-center representative should be able to understand the user’s state, and a paper or in-person path should not create a lower-quality outcome.

A confusing form may reflect unclear policy, an inaccessible document requirement, a fragmented data source, or a rule encoded differently across channels. Fixing the interface alone may only hide the deeper problem.

Cross-functional teams should include program, policy, legal, privacy, security, accessibility, content, design, engineering, data, and operations. HHS digital governance gives organizations a structure for coordinating standards and accountability across that work.

Product owners need authority to resolve conflicts and improve the service after launch. Accessibility defects, confusing content, and recurring support issues belong in the same prioritized backlog as new features.

Page views and completion counts do not explain who was excluded or how much effort success required. Pair quantitative measures with research, support data, accessibility testing, and feedback from frontline teams.

• Completion rate: Who finishes, and where do others stop?
• Time and effort: How long does the full journey take across channels?
• Error and rework: Which requests create repeated submissions or contacts?
• Accessibility: Which critical tasks can be completed with assistive technology?
• Equity: Do outcomes differ meaningfully across user groups or access conditions?
• Confidence: Do people understand the decision and what happens next?

Begin with a small, consequential journey. Research it, map it, prototype alternatives, test with representative users, and release a bounded improvement. Continue measuring in production and expand only when evidence supports the next step.

This rhythm makes human-centered design an operating practice rather than a workshop. It also creates a reliable way to discover accessibility barriers while they are still inexpensive to fix.

A human-centered HHS service respects people’s time, circumstances, abilities, language, and need for clarity. It connects policy and operations to an experience that people can actually navigate.

When accessibility, plain language, research, and measurement are built into delivery, digital services become more usable for everyone—and more capable of producing the public outcomes they were created to achieve.