iOS data deletion
Navigating platform and regulatory conflicts to produce a high-impact support solution.
At a glance

My roles
Content Designer and Strategist
Collaborated with
PM (Retention), Sr. Director of Client Support, Chief of Compliance, Engineers, Legal
Duration
~1.5 weeks from discovery to launch
Summary and problem
-
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
Solution
-
I 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
Impact
93.3% decrease in support emails (6% -> 0.4%)
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.

4 Backend 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.
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
I updated the CTA wording to reflect what the action actually does.

State-based flow architecture
I worked with our Retention PM and developers to design distinct, new flows for three identified subscription states.

Structured off-platform fulfillment
I worked with support to ensure an email template was included in the flow via Iterable to speed up data deletion requests.

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
3 Individual user flows
Combined into 1 flow

Flow summary
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

Outcomes
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
Future iteration 1
Run comprehension survey to ensure new data deletion language is fully understood
Future iteration 2
Run usability test to ensure users are entering correct state-based flow within data deletion funnel






