Designing a HIPAA compliance system for an open platform
Turning regulatory complexity into a scalable system for managing sensitive data across the platform
Wix · Wix Bookings · UX Lead · 2025
Overview
The Opportunity
Healthcare providers increasingly rely on their websites to manage appointments and collect sensitive patient data. However, strict regulations made Wix difficult to use for these workflows, forcing many businesses to rely on costly external HIPAA-compliant tools or avoid handling patient data on the platform altogether.
At the same time, Wix was seeing rapid growth in healthcare and mental health businesses, with rising expectations for compliance from both users and partners.
This tension between growth and regulatory limitations revealed a clear opportunity: enable secure patient data management directly within Wix, while unlocking new revenue potential.
In an open ecosystem like Wix, patient data flows across multiple touchpoints, making compliance a system-level challenge rather than a single feature.
Target Users
The primary users were small healthcare and wellness businesses that manage client appointments through their website. These included therapists, alternative health practitioners, and wellness providers such as massage or spa clinics.
About Wix Bookings
Wix Bookings is used to manage appointments and intake flows, making it a central touchpoint where sensitive health data can appear.
My Role
As a Senior Product Designer on the Wix Bookings team, I led the UX research and experience design for the HIPAA compliance initiative. I designed the activation flows, UX guardrails that help prevent compliance violations, and key parts of the compliance lifecycle while working closely with Legal, Security, Identity, and platform teams.
The Real Challenge
The challenge was not just meeting regulatory requirements, but adapting them to an open platform.
Unlike traditional healthcare products, Wix is an ecosystem of tools that users combine to run their business. Bookings, forms, apps, collaborators, and communication tools can all interact within the same site.
As a result, sensitive patient data can move across multiple touchpoints, often in ways users do not fully see or anticipate.
Designing for HIPAA was therefore not only about securing data, but about making data exposure visible and manageable. The product needed to help users understand where sensitive information might appear and guide them in configuring their site safely.
This led to a core design tension:
How can we protect sensitive data without limiting the flexibility that makes the platform valuable?
The Enforcement Dilemma
Once we understood how sensitive data flows across the platform, the core question became how HIPAA compliance should be enforced.
Through discussions with Legal and Product, I framed two possible approaches.
A strict enforcement model would block activation until all unsupported components were removed, ensuring strong regulatory protection but creating a significant barrier to adoption.
A guided compliance model would allow activation while surfacing risks and guiding users to resolve them over time.
To evaluate these approaches, I created high-level activation flows and used them to align stakeholders and validate assumptions through user interviews.
We learned that healthcare providers rely on multiple tools and third-party apps to run their practice. Blocking activation until every issue was resolved would likely prevent adoption altogether.
Based on these insights, I led the decision to adopt a guided compliance model, allowing users to activate HIPAA while making risks visible and manageable.
This decision shaped the foundation of the compliance system across the platform.
Strict enforcement
HIPAA activation is blocked until all unsupported components are removed.
Pros
Strong regulatory protection.
Cons
Creates a high activation barrier and may lead to user drop-off.
Guided compliance
HIPAA activation is allowed while highlighting unsupported components and guiding users to resolve them.
Pros
Allows users to activate HIPAA immediately and address risks progressively.
Cons
Requires ongoing monitoring and clear product guidance.
Mapping the Compliance Flow
Choosing a guided compliance approach meant compliance needed to be maintained over time, not only during activation.
To design this system, I mapped the full compliance lifecycle across the platform, identifying where protected health information could move between booking flows, forms, apps, and integrations. This mapping revealed that compliance should be treated as an ongoing lifecycle with four key stages:
Activation
Users enable HIPAA protection and sign the required agreement.
Monitoring
The system continuously evaluates actions that may affect compliance.
Risk detection
When a configuration introduces risk, the system identifies it.
Resolution
Users receive guidance on how to resolve the issue and return to a compliant state.
This framework helped define compliance as a system behavior rather than a one-time setup.
This shifted compliance from a one-time setup into an ongoing system behavior.
From Insight to Product
This required designing across multiple systems including bookings, forms, apps, permissions, and integrations.
UX interviews with healthcare businesses revealed that practitioners frequently modify their sites by installing apps and connecting integrations.
As a result, HIPAA compliance could not rely on a one-time setup.
Based on this insight, I designed a compliance model where compliance is treated as a system state rather than a static configuration.
Instead of relying on users to manually manage compliance, the platform continuously evaluates the site configuration and surfaces risks when they appear.
The solution focused on three key moments in the compliance journey:
Handling Risk During Activation
The activation flow evaluates the current system configuration and highlights potential compliance risks.
This allows users to understand the implications of their setup and resolve issues progressively during activation.
Detecting non-compliant apps
One of the most common risk sources is third-party apps and integrations.
Because Wix is an open ecosystem, the system continuously checks installed components and highlights non-compliant apps.
This helps users quickly identify which parts of their configuration may expose protected health information.
Reviewing affected components
When a risk is detected, users can immediately review the affected components from the compliance panel.
The review modal provides a clear overview of apps or integrations that may expose protected health information.
From there, users can navigate directly to the relevant configuration settings where incompatible apps can be removed or replaced.
This creates a clear path from risk detection → investigation → resolution.
Preventing Risk During App Installation
Risk prevention also extends beyond the activation flow.
Since businesses frequently extend their sites with new apps and integrations, the system surfaces compliance information earlier in the process.
HIPAA-compatible apps are clearly marked in the Wix App Market.
I worked with the App Market team to define how these compliance indicators appear in the marketplace, helping users identify compliant integrations before installation.
This shifts compliance awareness earlier in the decision process and helps users avoid introducing risk rather than fixing it later.
The Compliance Lifecycle
HIPAA compliance is not a one-time setup.
Compliance can change as the site evolves.
To support this, I designed a monitoring system that continuously evaluates actions across the platform.
If a change affects compliance, the system updates the compliance status and notifies the user.
Users can see their compliance status, understand what caused the issue, and follow clear steps to resolve it.
This allows compliance to be maintained over time rather than activated once and forgotten.
Change detected
Grace period
Non-Compliant
Change detected
The system continuously monitors the site's configuration and permissions.
If a change affects HIPAA compliance, such as a billing issue, a permission update, or an unsupported integration, the compliance status is updated and users are notified through in-product alerts and email notifications.
Change detected
Grace period
Non-Compliant
Grace period
When a change is detected, the site enters a 30-day grace period based on the user's billing cycle.
During this period compliance remains active while the system surfaces warnings and guides users to resolve the issue.
This prevents sudden disruption while still maintaining regulatory requirements.
Change detected
Grace period
Non-Compliant
Non-Compliant
If the issue is not resolved before the grace period ends, the compliance status becomes Non-Compliant and PHI protection is disabled.
Users can restore compliance at any time by resolving the issue and re-activating PHI protection.
Business Associate Agreement (BAA)
While technical safeguards help maintain HIPAA compliance, organizations must also meet legal requirements in order to process protected health information.
One of these requirements is signing a Business Associate Agreement (BAA).
To support this requirement, I designed the in-product agreement flow so organizations can review and sign the agreement as part of the HIPAA activation process.
Embedding the agreement directly within the interface removes the need for external legal workflows and allows organizations to complete the compliance setup within a single environment.
BAA requirement surfaced in the product
After PHI protection is enabled, the system clearly indicates whether the Business Associate Agreement has been signed and guides users to complete the agreement if it is missing.
If the agreement has not been signed, the interface highlights the requirement and provides direct access to the signing flow from the compliance settings.
This ensures the legal requirement remains visible while keeping the experience simple and integrated into the product.
Once signed, the agreement becomes part of the site's compliance record and is reflected directly in the compliance settings.
Users can access the agreement at any time for auditing or documentation.
Summary & Impact
Before launch, healthcare providers could not use Wix to manage protected health information in a compliant way.
Within the first months, adoption showed strong demand.
Over 14,000 sites explored HIPAA support, more than 3,300 initiated activation, and over 2,000 completed the process.
Because users could resolve risks instead of being blocked, completion remained high and no churn was recorded during the measured period.
86 percent of sites remained compliant over time, indicating that the system supports ongoing compliance, not just activation.
By turning compliance into a continuous and guided experience, we enabled healthcare providers to safely operate on Wix while unlocking a new product capability for the platform.
Adoption
14,063
Sites entered the HIPAA tab, indicating strong demand for HIPAA support on the platform.
Activation
3,353
Sites initiated HIPAA activation, showing clear intent to configure compliance.
Completion
2,070
Sites completed activation and successfully onboarded into the compliance system.
Because users could resolve risks instead of encountering hard stops, activation completion remained strong and no churn was recorded during the measured period.
Retention
86%
Sites remained compliant through their first billing cycle, demonstrating that compliance was maintained over time, not just activated once.
Reflections
This project showed that in open platforms, compliance cannot remain a policy. It must be designed as part of the system.
Instead of relying on users to understand regulation, the product needs to guide, monitor, and maintain compliance over time.
When Legal, Security, and Product teams operate through a shared product language, compliance becomes manageable and platform growth becomes possible.