UXcalibur
Available for work
←Back to UXcalibur

Free self-audit

The Regulated UX Checklist.

Twenty-four yes-or-no questions on the UX failure points that turn into audit findings, security incidents, and compliance problems after launch. Built for teams in MedTech, GovTech, LegalTech, and Fintech.

In a regulated product, a confusing screen is not just bad UX. It is a failed audit, a compliance finding, a security incident, or someone's money and health on the line. The interface has to enforce the rules as reliably as the backend does.

This is a quick self-check across the four areas I work in most. Go through the section that matches what you are building. Answer each item yes or no, honestly. Yes means the screen holds up. No means there is a gap worth looking at before it ships.

If you land on three or more no answers in any section, that usually means the compliance thinking is happening after design instead of during it. That is fixable, and it is most of what I do.

Jon Haines · UXcalibur

Get the PDF

Want a copy to take into a design review? It comes with a subscription to Design Breadcrumbs, my newsletter on the invisible rules that shape how regulated products get designed. Subscribe and the download link appears right here.

No spam. Unsubscribe anytime.

The self-audit

Answer the section that matches what you are building. Tap Yes or No on each item. Your no answers are tallied at the bottom.

MedTech & Healthcare

The bar is WCAG 2.1 AA at minimum, HIPAA shapes what can even be shown on screen, and health literacy means a confusing screen can affect someone's care.

  • 01Every patient-facing screen meets WCAG 2.1 AA, and you have checked it with an actual screen reader, not just an automated scanner.

  • 02Protected health information on screen (names, conditions, appointment details) is not exposed in a way a shoulder-surfer, a screenshot, or a shared-device session would leak. Sensitive fields can be masked or collapsed.

  • 03Any screen that shows a clinical number, dose, or result states its units and its normal range in plain language, so a patient is not left guessing.

  • 04Error and confirmation messages for anything health-related (booking, refills, results access) read at roughly an eighth-grade level and say what happens next.

  • 05Consent and authorization screens (sharing records, granting proxy access) show in specific terms who gets access to what, not one “I agree” checkbox over a wall of text.

  • 06Notifications and emails the product sends do not put health information in the subject line or the preview text.

GovTech & Security-Contracting SaaS

Contractor and defense-adjacent platforms do not get to fail quietly. A confusing permission structure is not a support ticket, it is a security incident.

  • 01What a user can see and do on any screen is driven by their role and clearance, and the UI hides what they cannot access rather than showing it greyed out.

  • 02Every state-changing action (approve, reject, escalate, release) records who did it, when, and under what authority, and that record is visible in the product, not only in a backend log.

  • 03When a record changes shape mid-workflow (a field set to yes adds new required fields, a status unlocks new actions), the interface makes the new requirements obvious instead of failing silently on submit.

  • 04A user can tell at a glance the current state of any record and what has to happen next, without asking a colleague or reading documentation.

  • 05Access reviews are supported in the product: someone can pull up who has access to what, and why, in a form an auditor would accept.

  • 06Least privilege is the default. New users and new roles start with minimal access and get more deliberately, not the other way around.

LegalTech

Legal workflows live and die on defensibility. Every screen has to make it obvious who did what, when, and under what authority, because that record may end up under real scrutiny later.

  • 01Every screen makes clear who took an action, when, and under what authority.

  • 02Permissioning is scoped to the matter, not just the user, so access follows the case and ends when involvement ends.

  • 03Privilege boundaries are enforced in the interface. A user who should not see privileged material cannot reach it through search, export, or a shared link.

  • 04The system produces a complete, human-readable activity history for any matter, document, or record, exportable in a form that holds up outside the product.

  • 05Destructive or irreversible actions (delete, purge, produce, waive) require deliberate confirmation and are themselves logged.

  • 06When information is incomplete or a required step was skipped, the product flags it rather than assuming it was done.

Fintech

Getting it wrong is a compliance failure, and it is also someone's money. The flows are disclosure-heavy and have to stay legible under regulatory review without becoming a wall of fine print.

  • 01Required disclosures (APR, fees, terms, adverse-action reasons) appear at the moment the decision is made, not on a separate page the user has to go find.

  • 02Disclosure text is legible: real font size, real contrast, no critical terms buried in a scroll box or a collapsed accordion.

  • 03Identity verification and onboarding tell the user why each piece of information is needed and what happens if verification fails, with a path forward rather than a dead end.

  • 04When an application is denied or a limit is set, the reason given is specific, not a vague “did not meet criteria.”

  • 05Every transaction screen shows the amount, the timing, the fee, and the counterparty before the user commits, and sends a confirmation they can keep.

  • 06Error states around money (failed transfer, hold, reversal) explain what happened to the funds and when they will be available.

What your answers mean

  • 3 or more no in a section. The compliance layer is probably being added after the fact. This is the pattern I get brought in to fix.
  • 2 no in a section. Worth a closer look. These gaps tend to compound as the product grows.
  • 0 to 1 no. You are in good shape. Keep compliance in the room during design reviews, not just after them.

If you are building in financial services

I have published a pattern library that goes deep on five of the flows above: KYC staged identity, APR disclosure, adverse action, privacy consent, and accessible authentication. Each one traces the rule that drives it, what the rule does and does not dictate, and how that shows up in the interface.

Designing Financial Flows→

Landed on three or more no answers?

That usually means the compliance thinking is happening after design instead of during it. A Regulated UX Audit turns those no answers into a scored report and a prioritized fix list in two weeks.

See the Regulated UX Audit

This checklist is a design self-assessment, not legal or compliance advice. Regulations change and vary by jurisdiction. Confirm specifics with your own counsel or compliance team.