Patient Comprehension and Usability Review

Before I start, we agree on three to five things a patient needs to be able to do, written in your words. Everything I find is tied to one of them. You also tell me who the product is for: the condition, the ages, the reading level you expect, the languages, the devices they use. If that has not been decided yet, that becomes the first thing in the report.

How serious a finding is depends on what could happen to the patient, not on how badly a page scored. There is a fixed list of rules. I work down it in order and use the first one that applies. The report names the rule behind every rating, so if you disagree with one, you can argue with the rule instead of taking my word for it.

1. Anything about medication, emergencies, what a patient is agreeing to, or what they will pay starts at Critical.
2. If there is a way around the problem but it means calling someone or asking staff for help, it stays Major. Needing a person is a problem with the product.
3. One Critical finding decides the verdict, however well everything else scored.

• I go through every screen and page against a written checklist, item by item, so a score is a measurement rather than my impression of a page.
• I measure reading level with three standard formulas and report all three, because they disagree with each other and one number on its own is misleading. Before I say a passage is too difficult to understand, I rewrite it once, keeping every medical term you have to keep, and measure again. If it becomes easier to read, the problem is the sentences. If it does not, the problem is the vocabulary, and the fix is to explain those words rather than remove them.
• I read each path once at normal speed, then write down without looking back what to do, when, what happens next, and who to call. Whatever I cannot recall is something a patient is unlikely to find.
• I go through each task, including the two situations where things usually break: someone enters something wrong, and someone leaves and comes back the next day.
• In the version with patient sessions, I ask each person to tell me in their own words what they would do. I report how many got it right out of how many I asked. With six or eight people, counts are honest and percentages are not.

The checklist is built on published federal tools for plain language and patient education, and on the Web Content Accessibility Guidelines 2.1 Level AA. Every one of them is named in the report. The rules for deciding how serious a problem is, and for reaching a verdict, are mine.

• A one-page summary with the verdict and the serious problems, written so it still makes sense to someone who reads only that page.
• Every problem I found, in order of how serious it is, with the evidence attached: the measurement, the screenshot, or the quote. Each one says what to do about it. If I cannot show you the evidence, it does not go in the report.
• A fix list in the order I would fix them, which is the part your engineering or content lead works from.
• A 45-minute call to go through it with you.
• One round of corrections after you have read it.

If I find something that could cause harm, you hear about it that day rather than at the end.

Two weeks means ten working days, and they start the day I get access to the product, not the day you sign. The version with patient sessions takes four to five weeks, because finding and scheduling patients sits in the middle of it.

For the version with sessions, finding participants and paying them is quoted separately. What you pay each person changes who agrees to come, not only how many, and a low payment tends to reach the patients your product already works well for. We decide that together before I start.

Start a conversation

• Whether the medical content is correct. That is your clinical team’s call, not mine.
• Legal, regulatory, or compliance sign-off. This review supports that work; it does not certify anything.
• Material in any language other than English, unless we add a reviewer who is fluent in that language.
• A full accessibility conformance audit of your codebase, or the formal report that goes with it.
• Making the changes. I tell you what to fix; your team fixes it.

More tasks, a second look after you make changes, a later version of the product, and training your team to use the checklist are all things I can do. Each is quoted separately.