Patient Portal UX Design Best Practices: Fixing Low Adoption

ASTP/ONC Data Brief No. 77 reported that 77% of individuals nationally were offered online access to their medical records in 2024. However, only 65% were offered access and actually accessed their patient portal.

The difference is important because availability does not demonstrate successful activation or sustained engagement.

Published institutional studies show even greater variation. A 2025 study at a large pediatric academic institution found that 47.7% of patients served over a decade had ever activated their patient portal.

A separate 2025 analysis of neurology patients in Washington, DC found 64.7% overall activation, with ward-level rates ranging from 48% to 82%.

These results should discourage healthcare organisations from treating a published activation rate as a universal target. Your patient population, clinical setting, authentication process, and communication strategy can materially change the outcome.

While building patient portals, we have found that the activation journey often reveals problems that remain invisible in broader portal usage reports.

Access is an infrastructure capability. Adoption is a user experience outcome.

A patient may receive portal credentials but abandon the process because activation requires several steps, uses unfamiliar terminology, or pushes the patient into a desktop workflow.

ASTP/ONC also reported that frequent portal use increased from 15% in 2019 to 34% in 2024. Frequent users were defined as individuals logging into their portal at least 6 times annually.

The increase shows meaningful progress, but it also highlights the difference between occasional access and habitual use.

For healthcare IT teams, that distinction changes what you measure. Activation rate alone cannot tell you whether patients successfully use messaging, appointments, results, forms, prescription requests, or other core tasks.

Three separate stages deserve measurement:

A fourth measure can show whether the portal has become part of the patient's normal healthcare workflow:

Your analytics should therefore identify where users abandon activation and which tasks they complete afterward.

A high activation rate followed by low task completion may indicate a navigation or mental model problem. A low activation rate points earlier, often toward identity verification, authentication, instructions, or the initial onboarding experience.

The activation process creates the first major judgement about your portal.

If the initial experience feels like an administrative obstacle rather than a route to a useful healthcare task, patients may abandon the process before seeing the portal's value.

Some activation journeys still rely on a sequence that was designed around administrative convenience rather than patient behaviour.

A patient may receive an activation code, open the portal on a phone, discover that the next step requires a desktop browser, and then encounter another authentication requirement.

Each additional transition creates another opportunity for abandonment.

Mobile-first activation does not mean removing security controls. It means designing the secure process around the devices, context, and task patients actually use.

Long onboarding forms create another common problem.

Patients may understand why demographic information or identity verification is required, but asking them to complete an extensive form before showing any useful portal function can weaken motivation.

Consider separating mandatory activation requirements from information that can be completed later.

For example, the first session might focus on identity verification and account setup. Additional profile information can then appear when the patient attempts a relevant task.

The goal is not to remove necessary information. It is to sequence the information according to patient intent.

A stronger activation flow answers one question quickly:

“What does this patient want to do next?”

That might mean booking an appointment, sending a message, viewing a result, completing intake, or requesting a prescription renewal.

Herexa Health provides a useful example of task-oriented healthcare platform architecture, where patient onboarding, medical intake, provider workflows, and consultation management were designed as connected parts of the broader experience.

For a portal redesign, map the first task before redesigning the first screen. Your interface should make the next meaningful action obvious without requiring patients to understand your underlying clinical data model.

Healthcare organisations often structure portals around how their systems store information.

Patients do not think in database categories.

They think about appointments, questions, forms, results, prescriptions, payments, and other immediate healthcare tasks.

A clinical dashboard can make sense to an internal product team because it reflects the information available inside the system.

Patients may approach the same interface with a completely different objective.

Someone who wants to book an appointment does not necessarily want to interpret a dashboard containing laboratory results, care summaries, and account notifications first.

The interface should recognise the difference between system structure and patient intent.

That means task labels should use language patients understand, while clinical terminology should appear where it helps rather than where it reflects internal system categories.

A useful portal homepage can prioritise common actions before secondary information.

For example:

The exact priority should come from your patient behaviour data and clinical workflows.

A good healthcare portal user experience design process therefore begins with task analysis, not visual styling.

If the homepage is difficult to understand, adding more features can increase rather than reduce cognitive load.

Once activation works, recurring usability problems can still prevent patients from returning.

These failures often sit between authentication, accessibility, navigation, and clinical workflow design.

MFA improves account protection, but poorly designed recovery flows can create an authentication dead end.

A patient may reset a password successfully but remain unable to complete the second authentication step. Repeating the process can create a cycle where every recovery attempt returns the patient to the same blocked state.

Map the complete recovery journey rather than testing password reset as an isolated screen.

Include scenarios such as lost credentials, changed phone numbers, expired verification codes, and failed authentication attempts.

Across recent compliance projects, we have seen how an MFA configuration can create unexpected reset loops during onboarding when the recovery journey was not tested end to end.

Patients should not have to understand the difference between clinical modules before completing routine tasks.

A portal may contain messaging, appointments, results, documents, payments, and forms, but patients generally approach these functions as individual jobs.

Use clear task labels and consistent navigation.

The same action should not appear under different names across different parts of the portal.

Authentication creates particular accessibility challenges because patients must often enter passwords, verification codes, security information, or other credentials.

WCAG 2.2 includes Accessible Authentication requirements that affect how authentication flows should be designed.

An accessible login process should also work with the assistive technologies and input methods your patient population uses.

Review error messages, focus management, keyboard navigation, field labels, verification steps, and recovery processes together.

For a deeper implementation framework, connect this work with our guide to accessible patient portal design and our complete WCAG 2.2 AA guide for healthcare.

Security controls can create usability problems when session expiration does not account for the task being performed.

Long intake forms are a clear example. A patient may spend significant time gathering information before submitting the form, only to discover that the session has expired.

Provide a visible warning before expiration and preserve information where the security model permits it.

The exact timeout should reflect your risk requirements and the nature of the workflow rather than applying the same experience to every portal function.

Patients build expectations from emails, SMS messages, printed instructions, and conversations with staff.

If those communications use different terminology from the portal, patients can struggle to identify the correct next step.

For example, an email might instruct a patient to “complete your pre-visit questionnaire” while the portal labels the same task “forms.”

Align the terminology across channels. Consistency reduces unnecessary support requests. It helps to reduce phone calls with patient self-service and gives patients a clearer mental model.

Usability testing does not require your design team to work with real patient records.

In fact, realistic synthetic data usually gives teams more control over test scenarios while reducing unnecessary exposure to PHI.

Synthetic data should reproduce the complexity required for the workflow without reproducing an actual patient's information.

A test account might contain:

The objective is behavioural realism, not clinical authenticity.

A test participant should be able to encounter the same decision points as a real patient without entering or viewing genuine medical records.

During healthcare implementations, we have used synthetic patient scenarios to evaluate intake workflows without placing real PHI inside the usability environment.

Screen recordings can capture information that testers did not intend to collect.

Avoid recording real patient accounts, actual medical records, real messages, or live production environments during usability research.

The same principle applies to screen sharing, analytics, session replay, screenshots, and research notes.

Your testing environment should have its own data handling rules, access controls, retention process, and approved participants.

For the security side of the architecture, connect your testing process with our breakdown of HIPAA technical safeguards.

Participants need enough realism to make meaningful decisions, but they should not need access to production information.

Give testers specific tasks rather than asking general questions about whether they “like” the portal.

For example:

Measure where they hesitate, what they misunderstand, and which labels they expect to see.

That evidence is more useful than subjective feedback about colours, spacing, or visual preference.

A portal redesign should connect adoption data with observed usability problems.

Use this checklist before committing to a major interface rebuild:

The checklist should support a broader diagnostic process, not replace it.

If your activation rate is low, determine where users leave. If activation is healthy but repeat usage is weak, investigate whether the portal solves the tasks patients actually want to complete.

That distinction can prevent a costly redesign focused on the wrong problem.

Patient portal adoption is not simply a question of whether access exists.

The 2024 national data shows a measurable difference between patients being offered online record access and patients actually accessing their portals. Published institutional studies also show that activation varies substantially across patient populations and settings.

For healthcare IT leaders, the practical response is to diagnose the complete experience. Measure activation, identify abandonment points, test authentication, simplify task entry, address accessibility, and validate workflows with realistic synthetic data.

A portal should reflect how patients think about healthcare tasks, not how your backend organises clinical information.

When usability, accessibility, security, and workflow design work together, your portal has a stronger foundation for sustained patient engagement.