Global Compliance & Accessibility Framework
CLS had been built and sold exclusively in the United States. As Clinisys expanded overseas, a leadership review of early product work surfaced an open question nobody had formally answered: was CLS actually ready to meet accessibility, usability, and data-protection requirements outside the U.S.? I researched and synthesized the applicable standards across the U.S. and U.K. into a design requirements framework the product team could act on.
CLS was a U.S.-only product, and no formal framework yet existed for how it should meet accessibility, data-protection, and security expectations in other markets. That gap became a visible problem as Clinisys expanded overseas: there was no shared answer for what "ready for those markets" actually meant.
As UX Researcher and Designer, I took on that question directly. Working alone, I researched the accessibility, usability, data-protection, and security standards that applied across the U.S. and U.K. — WCAG, Section 508, ADA, EN 301 549, the UK's Public Sector Bodies Accessibility Regulations, GDPR, HIPAA, ISO 9241, NIST guidance, and UK Cyber Essentials — and synthesized them into two visual models and a full design requirements framework the product, design, and engineering teams could use going forward.
The work was folded into a leadership presentation and the resulting checklist was handed to the product team as an ongoing reference for design and pre-release review, rather than a one-time document.
Contributions
- Researched applicable accessibility, usability, data-protection, and security standards across the U.S. and U.K. markets
- Built a Venn map showing where U.S. and U.K. requirements diverge and where they share common ground
- Built a second model showing how accessibility, usability, and security requirements intersect and reinforce one another
- Authored a full design requirements framework: over 45 individual requirements across accessibility, usability, security-adjacent UX, and privacy
- Defined a validation model and two design-process checkpoints for ongoing compliance review
- Presented findings, which were folded into a leadership presentation on international readiness
Method
This was desk research and regulatory synthesis, not user research in the traditional sense: reading the actual standards and translating each one into a concrete question of user impact and design response. I used Claude and ChatGPT to accelerate this research, since it drew entirely on public regulatory text with no internal or confidential data involved. No formal legal or compliance review existed to build from, so the frameworks below represent a first pass grounded directly in the regulatory text.
CLS had been designed, built, and validated against a single regulatory environment: the United States. As Clinisys expanded overseas, that single-market assumption stopped holding. Accessibility law, data-protection law, and security expectations differ by market, and none of them had been formally mapped against the product.
The gap surfaced when leadership reviewed early product work and asked, directly, whether CLS met accessibility and compliance expectations for the U.K. There wasn't a confident answer, because there wasn't yet a framework to answer it against. That's the problem this work set out to solve: not a specific screen or workflow, but the absence of a shared, actionable standard the whole product organization could design and build against.
Research Objectives
- Identify every accessibility, usability, data-protection, and security standard applicable to CLS in the U.S. and U.K.
- Map where those standards overlap versus where they diverge by market, to find the most efficient shared baseline.
- Translate abstract regulatory language into concrete, actionable design requirements specific to CLS's dense, data-heavy interfaces.
Why It Mattered
- Compliance gaps discovered late — during implementation or release review — are far more expensive to fix than ones caught at the design stage.
- International expansion was already the stated direction; the framework needed to exist before, not after, that work began in earnest.
The first step was mapping the landscape: which standards apply where, and which ones the U.S. and U.K. already share. WCAG and ISO 9241 turned out to be the most valuable finding — both markets already point to the same accessibility and usability baseline, which meant CLS could design to one bar instead of two, with market-specific requirements (Section 508, ADA, and HIPAA in the U.S.; PSBAR 2018, UK GDPR, and Cyber Essentials in the U.K.) layered on only where they genuinely diverge. From there, a second model reframed those same standards around how accessibility, usability, and security actually pull against each other in a dense clinical product — a security control can add friction; an efficient interface can still be inaccessible if it leans on color or mouse-only interaction. Both models fed directly into the requirements framework below.
Accessibility, usability, security, and privacy were treated as one experience, not four separate compliance activities — a change made for one should be checked against the others before it ships.
Standards don't translate into interfaces on their own. Every requirement in the framework follows the same four-step model, used consistently across all 52 items: Obligation → User Impact → Design Response → Evidence. For example, WCAG's keyboard-accessibility obligation becomes: a lab professional may be unable to use a mouse, so every worklist action, dialog, filter, and data-entry workflow must support keyboard interaction, verified by a keyboard-only task walkthrough.
The translation model applied to five representative requirements. Click to enlarge.
Accessibility
36 requirements covering contrast, keyboard operability, focus order, form labeling, error identification, data-table semantics, dynamic content, and more — grounded directly in WCAG 2.2 success criteria.
Usability
Consistency, system status, context preservation, cognitive load, and error prevention — ISO 9241 principles applied specifically to CLS's repetitive, safety-sensitive laboratory tasks.
Security-Adjacent UX
Authentication, role-based access, session state, and security messaging — where NIST and Cyber Essentials expectations show up directly in the interface, not just the backend.
Privacy & Data Protection
Data minimization, appropriate disclosure, consent, data rights, and auditability — translating GDPR and HIPAA obligations into what a screen should and shouldn't show.
| Prefer | Avoid |
|---|---|
| Persistent labels | Placeholder-only labels |
| Text + icon + color | Color-only status |
| Specific, corrective errors | "Invalid value" |
| Risk-based confirmations | Confirming every routine action |
| Persistent workflow context | Resetting filters after navigation |
I recommended this framework be incorporated directly into CLS's design system, so these patterns are enforced by default rather than re-evaluated on every new screen.
This work gave Clinisys its first formalized, actionable compliance framework for CLS — a direct answer to the question that prompted it. I applied it directly in my own subsequent design work, using the two review checkpoints — a structural review at the wireframe stage, and a visual and interaction review before final handoff — as part of my own process. The findings were folded into a leadership presentation on international readiness, and the checklist was distributed to the broader product team as a reference; team-wide adoption was slower, since embedding a new review discipline into an existing workflow takes more than handing over a document.
Next Steps
- Build stronger buy-in with the broader product team, since a document alone wasn't enough to shift day-to-day habits.
- Validate the framework against real CLS screens and workflows, since it was built from regulatory research rather than product-specific usability testing.
- Incorporate assistive-technology users into accessibility research directly, rather than relying solely on standards-based review.
- Track the EN 301 549 v4.1.1 revision and the European Accessibility Act as CLS expansion moves from the U.K. into the broader EU market.
This project sits apart from CLS's other case studies: there was no interview series, no prototype, no usability session. What it demanded instead was the ability to read a dozen overlapping, sometimes contradictory regulatory documents and turn them into something a design and engineering team could actually act on — a different kind of research, but the same underlying job of translating complexity into something usable.
It also marked a turning point for CLS's international strategy: the first time compliance and accessibility were treated as a design responsibility built into the process, rather than a legal question answered after the fact. That framework became the foundation for the next phase of CLS's expansion work.