What makes your ePRO actually easy to use?
Electronic patient-reported outcomes are only useful if participants actually complete them. And completion rates depend less on what the form asks than on how easy it feels to answer. A clinically perfect question set that nobody can navigate without confusion produces worse data than a slightly simpler one that everybody actually finishes.
The frustrating truth is that most ePRO usability problems are fixable. They come from design choices made without testing on real participants, and they show up as drop-off rates, inconsistent entries, and support requests that no one budgeted for.
What usability actually means here
Easy to use does not mean visually attractive. It means low friction: participants can read the question, understand what is being asked, and submit their answer without confusion or hesitation.
When that does not happen, one of a few things is usually going wrong:
- Instructions that assume clinical knowledge. If a participant does not know what an "adverse event" is, they cannot report one accurately.
- Multiple questions on one screen. Crowded layouts lead to missed items or accidental selections, especially on small phone screens.
- Rating scales that are inconsistent or poorly anchored. "1 to 5" means nothing without context. "1 = no pain, 5 = worst pain imaginable" is a different proposition.
- No confirmation that the submission worked. Participants who are not sure their entry saved will either re-submit (creating duplicate data) or give up.
Test it before you deploy it
The most reliable way to improve ePRO usability is to watch real people attempt to use it, before the study starts:
- Observe test participants completing the form from start to finish
- Ask them to think aloud as they go
- Note where they hesitate, re-read something, or make a mistake
- Time how long the whole thing takes
Three to five people doing this will surface most of the significant issues. This isn't a rule of thumb invented for convenience. It's grounded in a well-established finding from usability research: testing with five users tends to surface around 85% of a system's usability problems on average, based on a mathematical model of how consistently different users encounter the same issues. That figure varies meaningfully in practice, sometimes as low as half of all problems with a small group, sometimes considerably higher, which is itself a useful caveat. Five tests are a strong, cost-effective starting point, not a guarantee that nothing was missed. If the stakes are high enough (a long study, a vulnerable population, a complex form), testing a few more people than the bare minimum is a reasonable insurance policy.
This is not a large investment relative to the cost of a poorly completed ePRO across a full study. A single afternoon spent watching five people struggle through a form, and then fixing what they struggled with, is cheap compared to discovering the same problems three months into data collection, spread across hundreds of participants, with no way to go back and recapture what was lost to confusion the first time round.
Accessibility is not a bonus feature
Usability for participants with visual, motor, or cognitive differences is part of good design, not an optional extra:
- Sufficient contrast between text and background for participants with low vision
- Buttons large enough to tap reliably on a touchscreen
- Screen reader compatibility for participants who need it
- No reliance on colour alone to convey information
These considerations also tend to improve usability for everyone else, which is worth remembering when a stakeholder frames accessibility work as serving only a small minority of participants. Larger touch targets and clearer contrast help the tired, the distracted, and the person filling in a form on a moving train just as much as they help someone with a permanent visual impairment.
The purpose worth keeping in mind
An ePRO is there to collect participant experience, not to test digital literacy. The simpler and clearer it is, the more the data reflects reality rather than reflecting how well participants navigated the interface. That is worth designing for, and worth testing for properly before a single real participant ever sees the form.