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 healthcare client work and teaching examples 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.
Research in practice
The wellbeing case is real client work.
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.
Making onboarding work on a difficult day describes how individual sessions, diary research and co-design exposed the effort of getting started, reminder pressure and notification privacy. Read the full account of the research and recommendations.
Which service fits this vertical's most common trigger
In my 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, I'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.
Working on a health or patient-facing service?
Tell me about the service, how sensitive the information is and your patients’ access needs. I’ll recommend a method (testing, an accessibility evaluation, or both), not a default package.