Rossana BabakhaniAll case studies

Clinisys-Wide · Case study

Global Compliance & Accessibility Framework

Clinisys had been expanding into new markets faster than its compliance and accessibility groundwork could keep up. Was its software 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.

01 · Executive summary

Nobody had a confident answer to whether Clinisys's products actually met international requirements.

I researched the standards affecting Clinisys's products across the U.S. and U.K., including WCAG, Section 508, ADA, EN 301 549, PSBAR, GDPR, HIPAA, ISO 9241, NIST guidance, Cyber Essentials, the European Accessibility Act, and ISO 27001, then mapped where they overlapped, differed, and translated into product requirements.

WCAG and ISO 9241 covered U.S. accessibility and usability requirements and form a baseline the U.K. shares, so Clinisys could design to one bar and add market-specific requirements only where they diverge. For accessibility and usability, small changes made the products compliant.

02 · Approach

Desk research and regulatory synthesis, not user research in the traditional sense.

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
  • Authored a full design requirements framework: 52 requirements across accessibility, usability, security-adjacent UX, and privacy
  • Defined a validation model and two design-process checkpoints for ongoing compliance review

Method

I read the standards directly and translated each into a concrete question of user impact and design response. With no formal legal or compliance review to build from, the framework represents a first pass grounded directly in the regulatory text.

Research objectives

  • Identify every accessibility, usability, data-protection, and security standard applicable to Clinisys's products in the U.S. and U.K.
  • Map where those standards overlap versus where they diverge, to find the most efficient shared baseline.
  • Translate abstract regulatory language into concrete, actionable design requirements.

03 · Research & synthesis

WCAG and ISO 9241 turned out to be the most valuable finding: a baseline both markets already share.

The first step was mapping the landscape: which standards apply where, and which ones the U.S. and U.K. already share. That meant Clinisys 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. 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, and an efficient interface can still be inaccessible if it leans on color or mouse-only interaction. Session timeouts are one example: HIPAA calls for preventing unattended access to patient data, while accessibility requires warning users before a time limit and letting them extend it. The framework resolves both by warning before a timeout where policy permits and never losing entered data without warning.

Venn diagram of standards by market. U.K./Europe only: EN 301 549, Public Sector Bodies, GDPR, UK CUI, Cyber Essentials and Cyber Essentials Plus. U.S. only: Section 508, ADA, NIST, HIPAA. Shared by both: ISO 9241 and WCAG.
Standards by market: what the U.S. and U.K./Europe share, and where they diverge
Triangle diagram grouping standards by accessibility, usability, and security, with WCAG where accessibility and usability meet (how we design) and UK CUI where usability and security meet.
Standards by discipline: accessibility, usability, and security
12standards mapped, across 4 categories
2shared baseline standards (WCAG 2.2 AA, ISO 9241)
3U.K.-specific standards (PSBAR 2018, UK GDPR, Cyber Essentials)
52resulting design requirements

Design philosophy

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.

04 · Design requirements framework

Every requirement follows the same four-step model: Obligation → User Impact → Design Response → Evidence.

Standards don't translate into interfaces on their own. 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 52 requirements split across four categories:

Obligation to User Impact to Design Response to Evidence model, with example rows for WCAG keyboard operability, HIPAA session timeout, GDPR data minimization, Section 508 perceivable content, and EN 301 549 accessible ICT, feeding back into design and policy
The translation model applied to five representative requirements

Read the full framework ↗

Accessibility

36 requirements

Contrast, keyboard operability, focus order, form labeling, error identification, data-table semantics, and dynamic content, grounded directly in WCAG 2.2 success criteria.

Usability

7 requirements

Consistency, system status, context preservation, cognitive load, and error prevention, applied to Clinisys's repetitive, safety-sensitive laboratory tasks. Grounded in ISO 9241.

Security-adjacent UX

4 requirements

Authentication, role-based access, session state, and security messaging, where expectations show up directly in the interface, not just the backend. Grounded in NIST and Cyber Essentials.

Privacy & data protection

5 requirements

Data minimization, appropriate disclosure, consent, data rights, and auditability, translating obligations into what a screen should and shouldn't show. Grounded in GDPR and HIPAA.

PreferAvoid
Persistent labelsPlaceholder-only labels
Text + icon + colorColor-only status
Specific, corrective errors"Invalid value"
Risk-based confirmationsConfirming every routine action
Persistent workflow contextResetting filters after navigation

05 · Outcome

Clinisys's first formalized, actionable compliance framework.

This work gave Clinisys its first formalized, actionable compliance framework: a direct answer to the question that prompted it. I applied it directly in my own subsequent research work, using the two review checkpoints built into the framework. The framework and checklist were later absorbed into the design system and UX design principles, referenced in a development manager's own checklist, and incorporated into a company-wide documentation process guide. The findings were also folded into a leadership presentation on international readiness.

Next steps

  • Validate the framework against real product screens and workflows, including research with assistive-technology users.
  • Continue evolving the framework as Clinisys expands into additional markets and standards change.
A different kind of research

There was no interview series, prototype, or usability session here. The work instead required reading overlapping regulatory documents and turning them into something design and engineering could act on: a different kind of research, but the same underlying job of translating complexity into something usable.

Next case studyClinical Pathology Results Review →