CPIA Module 18, Section 5: User Experience (UX) and Accessibility Design
MODULE 18: TELEHEALTH & PATIENT-FACING INFORMATICS

Section 5: User Experience (UX) and Accessibility Design

Learn to design for everyone. We’ll cover the principles of user-centered design to create intuitive and engaging patient tools, and explore the critical importance of accessibility to ensure your technology is usable by patients with varying abilities and levels of health literacy.

SECTION 18.5

User Experience (UX) and Accessibility Design

Designing Digital Health with Empathy, Clarity, and Equity.

18.5.1 The “Why”: Design as a Determinant of Health

In the digital age, the design of our technology is becoming a social determinant of health. A well-designed patient portal can empower a patient to manage their chronic disease, adhere to their medications, and communicate effectively with their care team. Conversely, a poorly designed portal—one that is confusing, frustrating, or unusable—can become a significant barrier to care. It can lead to missed appointments, medication errors, and a profound sense of disempowerment for the patient. For a 75-year-old patient with low vision and early-stage dementia, a portal with small, low-contrast text and a complex navigation structure is not just an inconvenience; it is an insurmountable wall preventing them from accessing their own health information. In this context, bad design can cause real, clinical harm.

This is why User Experience (UX) and Accessibility (often abbreviated as A11y) are not optional aesthetic refinements or “nice-to-have” features. They are fundamental pillars of patient safety, health equity, and clinical quality. A technology is only as effective as a patient’s ability to use it. The most sophisticated predictive algorithm or the most comprehensive lab data is useless if the patient cannot find it, understand it, or act upon it. The principles of good design are about removing barriers and building bridges between the patient and their health information.

As a pharmacy informatics analyst, you are uniquely positioned to be a champion for the user. You understand both the complexity of the clinical data and the real-world challenges patients face in managing their health. You are the translator, the advocate, and the architect who ensures that the voice of the patient is at the center of every technology decision. This section is designed to provide you with a masterclass in the foundational principles of user-centered design, usability, and accessibility. Your role is not necessarily to become a professional designer, but to become an expert collaborator and a discerning critic who can distinguish a truly patient-centered design from a merely functional one, ensuring that the technologies you implement serve to close gaps in care, not widen them.

Retail Pharmacist Analogy: The “Perfect” vs. the “Impossible” Pharmacy Layout

Imagine two pharmacies. Both have the exact same medications, the same computer system, and equally skilled pharmacists. From a purely clinical standpoint, they are identical.

Pharmacy A (The “Impossible” Pharmacy): The drop-off window is unlabeled and located in the back of the store. The aisles are narrow and cluttered, making it impossible for someone with a walker or in a wheelchair to navigate. The prescription labels are printed in a tiny, 6-point font. The consultation window has no privacy, and the pharmacist speaks in rapid-fire medical jargon. To pick up a prescription, a patient has to navigate a confusing maze and struggle to read and understand vital information. Many will simply give up or make mistakes with their medication out of sheer frustration and confusion. This is a poorly designed user experience.

Pharmacy B (The “Perfect” Pharmacy): The signage is large, clear, and uses simple language (“Prescription Drop-Off,” “Pick-Up,” “Talk to a Pharmacist”). The aisles are wide and clear, meeting ADA accessibility standards. Prescription labels use a large, 12-point font with key instructions highlighted. The consultation window is a private, sound-proofed room where the pharmacist takes the time to explain things in plain language, using diagrams and “teach-back” methods. The entire physical space has been intentionally designed around the needs of the user, especially the most vulnerable. This is a well-designed user experience.

A patient portal is a digital pharmacy. As an informatics analyst, you are the architect of that digital space. You can either build the confusing, inaccessible maze of Pharmacy A, or you can build the clear, empowering, and accessible environment of Pharmacy B. The underlying data (the “medications”) might be the same, but the design of the interface determines whether patients can actually access, understand, and benefit from it. Your expertise in UX and accessibility is what allows you to build Pharmacy B in a digital world.

18.5.2 A Masterclass in the User-Centered Design (UCD) Process

Great user experiences do not happen by accident. They are the result of a disciplined, empathetic, and iterative process known as User-Centered Design (UCD). The core philosophy of UCD is simple but profound: design decisions should be driven by the needs, goals, and limitations of the end-user, not by the assumptions of the design team or the capabilities of the technology. As an informatics analyst, you will be a key participant and facilitator of this process. It involves moving from “I think users want…” to “Our research shows users need…”

The Iterative Cycle of User-Centered Design

1. Discover

Understand the user and their context. Who are they? What are their goals? What are their pain points? (Research)

→
2. Define

Synthesize the research into clear problem statements, user personas, and design requirements. (Analysis)

→
3. Design

Generate potential solutions, starting with low-fidelity sketches and moving to high-fidelity, interactive prototypes. (Ideation)

→
4. Test

Evaluate the design with real users through structured usability testing to identify flaws and gather feedback. (Validation)

←

Iterate based on feedback

→
Deep Dive into the UCD Phases: The Analyst’s Role
UCD Phase Core Objective Common Methods Your Role as a Pharmacy Informatics Analyst
1. Discover To build empathy and gain a deep understanding of the users, their environment, their goals, and their current challenges.
  • User Interviews: One-on-one conversations to explore a user’s experiences and attitudes in depth.
  • Surveys: Quantitative data collection from a large user group.
  • Contextual Inquiry: Observing users in their natural environment to understand their workflow.
 You are the Subject Matter Expert (SME). You can help the design team understand the clinical context. You can say, “Let’s make sure we interview patients who are on warfarin and have to manage frequent INR checks, as their needs are unique.” You can also help recruit appropriate patients for these research activities.
2. Define To synthesize the qualitative and quantitative data from the discovery phase into actionable insights and clear design goals.
  • User Personas: Fictional but realistic profiles of key user types (e.g., “Tech-Savvy Tina,” “Caregiver Carl,” “Offline Oscar”).
  • Journey Maps: Visualizations of the user’s step-by-step experience with a current process, highlighting pain points and opportunities.
 You help create clinically realistic personas. You can map out the current, frustrating journey of a patient trying to get a prior authorization approved, identifying every phone call, fax, and delay. This map becomes a powerful tool to show stakeholders exactly what problem you are trying to solve.
3. Design To brainstorm and create tangible representations of the solution, starting broad and progressively adding detail.
  • Wireframes: Low-fidelity, black-and-white blueprints of a screen’s layout and structure.
  • Mockups: High-fidelity, static but visually polished representations of the final interface.
  • Prototypes: Interactive mockups that allow users to click through a workflow as if it were a real application.
 You provide critical feedback on the clinical safety and workflow feasibility of the designs. You can look at a wireframe and say, “This is a good start, but you are missing a place to display the patient’s renal function, which is essential for dosing this medication. Also, the ‘override’ button is too prominent and could encourage unsafe actions.”
4. Test To evaluate the design’s effectiveness by observing real users interacting with the prototype. The goal is to find and fix usability problems before any code is written.
  • Moderated Usability Testing: A facilitator guides a user through a set of tasks, asking them to “think aloud” as they work.
  • Heuristic Evaluation: An expert review of the interface against established usability principles.
 You help write the test scripts to ensure they reflect realistic clinical scenarios. You can serve as an expert reviewer in a heuristic evaluation. Most importantly, you are a key observer during usability tests, listening for moments where a patient’s mental model does not match the system’s design, which often reveals critical design flaws.

18.5.3 A Masterclass in Accessibility (A11y) Design

Accessibility is the practice of designing products, devices, services, or environments for people with disabilities. In the digital world, this means ensuring that our websites and applications can be used by everyone, regardless of their physical, sensory, or cognitive abilities. This is not only an ethical imperative and a component of health equity but also a legal requirement in many countries, including under the Americans with Disabilities Act (ADA) in the United States. As an informatics analyst, you must be a relentless advocate for accessibility, embedding it into every stage of the design and development lifecycle.

Accessibility is Not a “Feature” or an “Add-On”

One of the most critical mistakes in technology development is treating accessibility as a final checklist item to be addressed after the product is already built. This is akin to building a three-story building and then trying to figure out how to add an elevator. It is expensive, inefficient, and often results in a clunky, “bolted-on” solution. True accessibility is achieved when it is considered a core design principle from the very first sketch, just like security or usability. This is often called the “shift-left” approach—moving A11y considerations to the earliest stages of the project timeline.

The Four Foundational Principles of WCAG (POUR)

The Web Content Accessibility Guidelines (WCAG) are the global standard for web accessibility. They are organized around four high-level principles, known by the acronym POUR. For an interface to be accessible, it must be Perceivable, Operable, Understandable, and Robust.

Principle Core Question Who it Helps (Examples) Key Informatics & Design Considerations
Perceivable Can users perceive the content? Users who are blind, low-vision, or deaf.
  • Alt Text for Images: Every image that conveys meaning must have a text alternative. A screen reader will read this text to a blind user. Decorative images should have empty alt text (`alt=””`).
  • Color Contrast: Text and background colors must have a sufficient contrast ratio (at least 4.5:1 for normal text) to be readable for users with low vision or color blindness.
  • Captions & Transcripts: All video content must have synchronized captions for deaf or hard-of-hearing users. A full transcript should also be provided.
  • Don’t Rely on Color Alone: Do not use color as the only way to convey information. For example, next to an abnormal lab value, use both a red color and an icon (like an exclamation mark) with a text label (“High”).
Operable Can users operate the interface? Users with motor disabilities who cannot use a mouse, users with tremors, photosensitive users.
  • Keyboard Accessibility: Every single interactive element (link, button, form field) must be accessible and operable using only the Tab, Enter, and arrow keys. This is one of the most critical and often-failed A11y tests.
  • No Keyboard Traps: A user must be able to navigate into and *out of* every component using the keyboard. A common failure is a pop-up window that “traps” the keyboard focus.
  • Sufficient Time: If a session times out, the user must be able to request more time. Content should not flash or blink in a way that could trigger seizures (less than 3 flashes per second).
  • Large Click Targets: Buttons and links should have adequate size and spacing to be easily tapped by someone with a motor tremor or on a small mobile screen.
Understandable Can users understand the content and the interface? Users with cognitive disabilities, learning disabilities, or low health literacy. (In truth, this helps everyone).
  • Plain Language: Write content at a 6th-8th grade reading level. Avoid jargon, acronyms, and complex sentence structures. Your pharmacist skill of patient counseling is directly applicable here.
  • Predictable Navigation: The navigation should be consistent across all pages. A link that says “Appointments” should always go to the same place.
  • Clear Error Messages: When a user makes a mistake (e.g., enters a date incorrectly), the error message should be specific and helpful (“Please enter the date in a MM/DD/YYYY format”) rather than generic (“Invalid input”).
  • Logical Reading Order: The underlying code should ensure that a screen reader reads the content in the same logical order that a sighted user would see it.
Robust Can the content be interpreted by a wide variety of technologies? Users who rely on assistive technologies like screen readers, screen magnifiers, or voice control software.
  • Use Standard HTML: Adhere to web standards. Use native HTML elements for their intended purpose (e.g., use a `
  • Use ARIA Attributes: When standard HTML isn’t enough, use Accessible Rich Internet Applications (ARIA) attributes to provide additional semantic information to assistive technologies (e.g., `role=”alert”` for a dynamic error message).
  • Ensure Compatibility: Test the portal on different browsers, operating systems, and with common screen readers (like JAWS, NVDA, and VoiceOver).

18.5.4 The Intersection of Usability, Health Literacy, and Design

While UX and Accessibility provide the framework for usable design, the effectiveness of a patient-facing tool ultimately hinges on its content. This is where the concept of health literacy becomes paramount. Health literacy is a patient’s ability to obtain, process, and understand basic health information and services needed to make appropriate health decisions. A portal can be perfectly usable and accessible, but if it presents information in a way that is medically dense and context-poor, it fails the patient with low health literacy.

You Are the Health Literacy Expert

As a pharmacist, you are a master of translating complex clinical information into understandable, actionable instructions for patients every single day. When you counsel a patient, you don’t just read the package insert. You use plain language, focus on the 2-3 most important points, check for understanding with teach-back, and use analogies. This is the exact skill set required to design content for patient portals. Your clinical expertise must be paired with your communication expertise to be effective.

A Practical Example: Redesigning a Lab Result Display

Let’s apply these principles to a common informatics task: designing how a basic metabolic panel is displayed in a patient portal.

The Poorly Designed Display

(Fails on Usability, Accessibility, and Health Literacy)

Test: Na | Result: 132 | Range: 135-145 | Flag: L

Test: K | Result: 4.1 | Range: 3.5-5.0 | Flag:

Test: Cl | Result: 95 | Range: 98-107 | Flag: L

Test: BUN | Result: 25 | Range: 7-20 | Flag: H

Test: Cr | Result: 1.4 | Range: 0.6-1.2 | Flag: H

Why it Fails:
  • Jargon: Uses abbreviations like “Na,” “K,” “BUN,” “Cr.”
  • Low Context: What do these numbers mean? Why were they ordered?
  • Poor Accessibility: “L” and “H” flags rely on being able to see them. Color might be used alone, failing colorblind users.
  • High Cognitive Load: The user has to manually compare each result to the range and interpret the flag.

The Well-Designed Display

(Embraces Usability, Accessibility, and Health Literacy)

Basic Metabolic Panel (Kidney & Electrolyte Check)

Result from Oct 18, 2025

Sodium: 132 (Low)
Normal: 135-145

Potassium: 4.1 (Normal)
Normal: 3.5-5.0

Chloride: 95 (Low)
Normal: 98-107

BUN (Kidney Function): 25 (High)
Normal: 7-20

Creatinine (Kidney Function): 1.4 (High)
Normal: 0.6-1.2

Your provider has seen these results. The slightly high kidney numbers may be related to your new blood pressure medicine. Your provider will discuss this with you at your next visit.
Why it Succeeds:
  • Plain Language: “Sodium,” “Kidney Function.”
  • Context Provided: Gives the name of the test panel and a very brief, plain-language comment from the provider.
  • Accessible Flags: Uses color, a word (“Low”), and bold text to indicate an abnormal result.
  • Low Cognitive Load: It’s immediately clear which results are normal and abnormal without mental math.