Cerebral
👤 My roles
Content Designer and Strategist
iOS data deletion
Here's how I used language and IA to reduce operational burden and compliance risk
👥 Collaborated with
PM (Retention), Sr. Director of Client Support, Chief of Compliance, Engineers, Legal
🗓️ Duration
~1.5 weeks from discovery to launch
💥 Impact
93.3% decrease in support emails (6% -> 0.4%)
Challenges
-
iOS users trying to cancel their Cerebral subscriptions were instead entering a data deletion flow due to unclear CTA wording
-
Support was burdened by recurring efforts redirecting users to the correct flow
-
Data deletion flow did not account for different user states, lacked explicit wording, and did not clearly specify legal constraints and consequences of deleting data
Solutions and process
-
Clarified intent at the flow entry point (CTA)
-
Introduced state-based logic that reflected user subscription statuses (Active, Cancelled, Cancellation in progress)
-
Merged legal and operational requirements into a structured flow
User and business risks
Operational costs
Support teams were repeatedly redirecting iphone users who were trying to cancel their subscriptions, but instead were ending up in a flow about deleting their data.
This was creating avoidable ticket loops and accounting for 6% of support requests, tracked via Zendesk.
Regulatory exposure
Due to unclear wording, users were initiating full account deletion without understanding what data would legally remain.
This created risk of misinterpretation, compliance scrutiny, and potential legal complaints.
Platform dependencies
Apple required in-app account deletion (and associated data deletion request) for apps that support account creation.
This limited our ability to redesign or remove the flow entirely, forcing us to resolve confusion within strict platform guidelines.
Retention tension
The Retention PM and Sr. Director of Client Support required intentional friction in the cancellation experience to reduce churn.
Clarifying the deletion flow risked making subscription cancellation easier, requiring careful separation of the two processes without undermining business goals.
Constraints
🚫 Apple mandate
We were required to provide in-app data and account deletion for iPhone users.
Apple’s App Store policy required that any app offering account creation must also provide a way to request account and data deletion in-app.
Removing or hiding the flow was not an option, so the solution had to work within Apple’s compliance requirements.
🚫 HIPAA restrictions
Per HIPAA, we could not delete all client records.
As a healthcare provider, Cerebral was legally required to retain certain medical records even after a user requested data deletion.
This meant we could not promise full account erasure, and had to clearly communicate what could and could not be deleted.
🚫 Technical timeline limits
A full architectural redesign was out of scope.
Engineering bandwidth was limited. Timelines did not allow for building a fully unified cancellation and deletion system.
The solution had to work within the existing architecture and be implemented quickly without significant backend changes.
🚫 Retention friction requirements
We could not make cancellation "too easy" for users.
The Retention PM and Chief of Support wanted to include intentional friction to reduce churn.
Any changes to the deletion flow could not create a shortcut or loophole that allowed users to bypass the existing cancellation process.
Intervention
Intent clarification at entry point
CTA update to reflect what the action actually does
State-based flow architecture
Designed distinct flows for three subscription states
Structured off-platform fulfillment
Email template to speed up data deletion requests.
Flow summary
Before
-
1 flow for all user groups
-
No email template
-
No subscription cancellation requirement stated at entry point
-
This meant more work for support to untangle on a case-by-case basis
-
After
-
Separate flows for 3 identified user groups
-
Email template for all groups
-
Clear differentiation between subscription cancellation and data deletion at entry point, to reduce support burden and client confusion
Outcomes
Metrics
-
Eliminated recurring cancellation misinterpretation
-
Reduced support redirection loops
-
Removed regulatory ambiguity from deletion entry point
-
93.3% reduction sustained over 2 months
-
No recurrence of cancellation confusion spike
Takeaways
🏗️ Architectural management
By preventing two legally distinct flows from sharing the same entry point
🤝 Business-aligned clarity
By balancing stakeholder needs with legal transparency
📈 Operational scalability
By reducing support burden while preserving compliance
Reflections
How much do users benefit from the new copy and architecture?
Future iterations:
-
Run comprehension survey to ensure new data deletion language is fully understood
-
Run usability test to ensure users are entering correct state-based flow within data deletion funnel