Healthcare and patient-facing digital services carry a specific kind of UX risk. A confusing checkout costs a sale; a confusing consent screen or a patient portal someone can't register for costs something closer to trust in a care relationship. This page groups our healthcare-adjacent example engagements in one place and explains the questions this sector tends to raise before you commission research.
What makes healthcare UX problems distinct in Ireland
Four things tend to separate healthcare and patient-facing research from a typical commercial UX project.
Consent. Patients are frequently asked to agree to something — sharing records between services, being contacted about results, taking part in a programme — and the wording has to be genuinely understood, not just technically present. A consent screen that scores well on a checklist can still leave a patient unsure what they actually agreed to. Research in this space needs to test comprehension, not just presence.
Identity verification. Patient portals and health-adjacent services usually need to confirm they are speaking to the right person before showing anything sensitive. That verification step has to be strict enough to protect health information and forgiving enough that a patient who is anxious, unwell, or unfamiliar with online forms doesn't abandon registration at the first hurdle. Getting that balance wrong either leaves the service insecure or locks out the people who need it most.
Sensitive information. Health data sits in a more sensitive category than most personal information handled online, which shapes both the legal obligations around it and the tone it needs to be presented in. Results, diagnoses, medication and treatment programmes have to be communicated in language that informs without alarming, and interfaces need to anticipate that some readers will be encountering this content at a difficult moment.
Accessibility needs. People interacting with healthcare services skew toward a wider range of ages, digital confidence levels, temporary and permanent disabilities, and assistive technology use than a typical commercial audience. A patient recovering from a procedure, managing a chronic condition, or supporting an older relative through a portal is not an edge case in this sector — it is a large part of the real audience, so accessibility has to be built into the research plan rather than treated as an afterthought.
Example engagements
The two engagements below are clearly labelled, illustrative example write-ups — they show how we approach this kind of brief and the questions a study in this space typically needs to answer. They are not case studies from named, verified real clients, and no specific findings, participant counts or outcome figures should be read as claims about any particular organisation.
Making a patient portal easier to register for and understand walks through an example engagement built around the registration and account-access journey for a patient portal: identity checks, booking and viewing appointments, understanding results, the wording used for consent, where to find support, and testing with participants who had different access needs. It's the clearest illustration of how the four issues above — consent, identity, sensitivity and accessibility — show up together in a single flow, and why a portal that "works" in a walkthrough can still fail patients who don't match the tester's assumptions.
Helping a recovery app earn trust during onboarding looks at a different kind of healthcare-adjacent pressure: a substantial opening diagnostic, daily prompts, reminder pressure and an eight-week support programme, in a context where the user's willingness to keep going matters as much as whether they can operate the interface. The example is deliberately framed around not confusing task completion with earned trust — someone can tap through an onboarding flow without ever believing the service is on their side, and that gap is exactly what usability research in sensitive, recurring-use products needs to surface.
Which service fits this vertical's most common trigger
In our experience scoping this kind of work, healthcare and patient-facing briefs tend to start from one of two triggers, and they point to different services.
If the open question is whether patients can actually complete a specific journey — registering, verifying their identity, booking, reading results, understanding consent wording — that's a usability testing question. Moderated sessions with participants who reflect the real range of your patients, including different digital confidence levels and access needs, will show you where the flow breaks down and why, rather than leaving the team guessing from analytics alone.
If the open question is closer to "does this meet the accessibility and inclusion standard we need it to," that's an accessibility audit question — a scoped evaluation against an agreed WCAG version and level, using automated checks and manual review as complementary evidence rather than either one standing alone. For healthcare services specifically, we'd usually recommend involving disabled users and assistive-technology users directly where the scope allows it, since a standards-based review and testing with real users answer related but different questions.
Many healthcare briefs end up needing both: an accessibility evaluation to establish the standards baseline, and usability testing to check that the flow actually makes sense to the people using it. The right starting point depends on which uncertainty is larger for your team right now — that's exactly what the brief call is for.
Scoping a healthcare or patient-facing project?
Use the brief call to describe the journey, the sensitivity of the information involved, and the access needs of your patient group. We'll recommend a method — testing, accessibility evaluation, or both — rather than defaulting to one service.