Designing patient portals that people actually use

You spent months building a patient portal. It has secure messaging, records access, appointment booking, the lot. And six weeks after launch the support line is still ringing off the hook, because patients cannot find their test results, cannot read the tiny grey text, or gave up at the login screen and called the clinic instead. The features are all there. The portal is technically complete. And almost nobody is using it.

This is the most common failure mode in patient software, and it has very little to do with whether the engineering works. A portal does not get abandoned because a feature is missing. It gets abandoned because using it is harder than picking up the phone. The people on the other end are often stressed, unwell, older, or all three, and they did not choose to become users of your software. They are forced to, on a bad day. Designing for that reality is the whole job.

Accessibility is a hard requirement, not a nice-to-have

Start here, because it is the part most teams treat as optional and then regret. A meaningful share of any patient population uses assistive technology: screen readers, screen magnifiers, voice control, keyboard-only navigation, high-contrast modes. In a general consumer app you might rationalise ignoring them. In healthcare you cannot, both because the proportion is higher and because excluding a patient from their own medical records is not a minor UX miss.

The encouraging part is that most of the wins come from a small set of fundamentals, the same ones we cover in accessibility for developers: real semantic HTML so a screen reader can announce what things are, every control reachable and operable by keyboard, visible focus states so people can see where they are, labels tied to their inputs, and colour contrast high enough to read in a hospital corridor. You do not need to memorise a standards document to get most of the way there. You need to build with semantic markup from the start and test with a keyboard and a screen reader before you ship, not after a complaint. Retrofitting accessibility onto a finished portal is painful; building it in from the first component is nearly free.

Plain language beats clever design

Patients are not your colleagues. They do not know that "EOB" means explanation of benefits, that "encounter" is what you call a visit, or which of the six menu items hides their prescription refills. Clinical and billing jargon leaks into portals constantly because the people building them are steeped in it, and every leak is a patient who hesitates, guesses wrong, or gives up.

The fix is unglamorous and effective: write like you are explaining things to a worried person who is not feeling their best.

• Name things the way patients do. "Your test results," not "Diagnostic outputs." "Messages with your care team," not "Secure communications module."
• Say what will happen before it happens. "We'll send a code to your phone to confirm it's you" tells someone what to expect. A bare "Verify" field tells them nothing.
• Make errors human. "That date of birth doesn't match our records, please check the format is DD/MM/YYYY" helps. "Validation error 422" sends them to the phone.

This is part of why a shared design system matters more than it looks: when your labels, buttons, and messages are defined once in clear language, the clarity is consistent everywhere instead of depending on whichever developer wrote that screen.

Reduce friction for people having a bad day

Assume your user is stressed, possibly in pain, possibly helping an elderly parent who is not comfortable with technology. Every extra step, every tiny tap target, every surprise is a place they fall out.

A few patterns do most of the heavy lifting. Make text large and resizable, and never trap it at a size that defeats someone who pinches to zoom. Make tap targets generous, because shaky hands and small screens do not mix. Keep the path to the three things people actually came for, results, messages, appointments, short and obvious, rather than burying them under a tidy-looking menu. Do not force a password reset gauntlet on someone who logs in twice a year; offer a sane recovery flow and clear, patient guidance instead of a wall. And respect that many of your users are on an older phone with a patchy connection in a waiting room, which brings us to the unglamorous foundations.

Mobile and reliability are features

A large share of patients will only ever open your portal on a phone, often a few-years-old one, often on hospital wifi that barely works. If the portal is slow to load, breaks on a small screen, or falls over when the connection wobbles, none of your careful UX matters, because they never reach it.

So treat performance and resilience as features patients can feel, not back-office concerns. Pages should load fast on a mid-range phone, not just on your laptop. The layout should work at 360 pixels wide, not assume a desktop. And the portal has to be genuinely reliable: when someone logs in at 6am because they are anxious about a result, "down for maintenance" is a betrayal of trust they may not extend twice. Getting this right is a real part of building the web app, and it is the kind of customer-facing reliability we dig into in building a customer portal. Patient portals are customer portals where the stakes are higher and the patience is lower.

Secure messaging and records access, done calmly

The two features patients value most, reading their own records and messaging their care team, are also where trust is won or lost. Both touch sensitive health data, so they have to be built carefully, with proper access control and encryption, within the boundaries we cover for any healthtech product. But the patient should never feel the machinery.

For records access, show results in plain terms with enough context that a number does not cause needless panic, and make it obvious what is new since last time. For messaging, set honest expectations: tell people roughly when they will hear back so they are not refreshing the screen at midnight, confirm clearly when a message has sent, and never silently drop one. The security has to be invisible and the communication has to be human. When those two things are true, patients start trusting the portal enough to use it instead of the phone, which was the entire point.

The takeaway

A patient portal does not succeed because it has every feature. It succeeds because a stressed, tired, possibly older person, maybe using a screen reader on an old phone in a waiting room, can find what they came for and get out without calling the clinic. That means accessibility treated as a requirement, plain language instead of jargon, ruthless removal of friction, and the boring reliability that makes the whole thing trustworthy.

Build for the patient on their worst day and the portal works for everyone on every other day too. If you have a portal patients are quietly abandoning, or you are designing one and want to get it right the first time, tell us what you are building. That is the good kind of lazy: doing the unglamorous accessibility and clarity work up front so your support line goes quiet.