GDPR & CCPA
To comply with global and local law, we built a site for users to delete their accounts and download their data. Besides compliance, it’s the right thing to do.
In 2018, the compliance date for the General Data Protection Regulation & California Consumer Privacy Act took effect. These regulations require businesses, including Lyft, to give their users the ability to download their data and delete their own account.
Problem
Lyft’s processes for doing both of these actions existed before, but the processes were manual and time consuming. To scale, we needed to build a self-service site (a “privacy portal”) for account deletion and data requests.
Solution
The internal team assembled to ensure Lyft’s compliance with GDPR and CCPA was about 200 folks, mostly legal, risk, compliance, and eng stakeholders. There were many moving parts to execute both the technical and experiential pieces of the project, and with a fast deadline, there wasn’t time for the traditional design process.
From a content design perspective, the experience needed to be as straightforward and simple as possible. Because of the legal risk involved, I focused on functionality and simplicity over the usual fun tone popular at Lyft.
I identified the opportunity for saving some account deletion by researching the reasons why users typically contacted support to delete their account. This part of the work moved metrics the team wasn’t expecting and saved considerable cost.
Approach
The privacy portal isn’t indexable online, so users are required to log into lyft.com to view it. This was a decision made in tandem with the SEO and legal teams.
After starting the account deletion flow, this screen prompts the user to optionally say why they’re deleting their account.
For users who had an adverse experience during a ride with Lyft, we wanted to collect any extra data to help ensure future safety from both rides and drivers.
The account issue option is a more general feedback mechanism, one intended to capture any additional user data that might be useful.
Deleting an account is a permanent, destructive action. Data showed evidence of users trying to get back deleted accounts, hence I included this screen in the flow.
Just because someone has deleted their account with Lyft doesn’t mean this part of the experience isn’t still Lyft. I maintained the familiar voice but changed the tone to meet the moment. The subhead provides confirmation Lyft will delete the account.
After starting the data download flow, the privacy portal displays this message, which explains the expectations for what Lyft is doing in the backend and when the user can expect their data.
The backend processing of data downloads wasn’t initially instantaneous. Because many users expect everything on the internet to move quickly, I set clear expectations about the timeline again.
This interstitial screen adds a click for the user but was necessary as a technical limitation at the time.
This design is an accommodation for a technical limitation. Showing two headlines and CTAs can cause high cognitive load. First, I’ll walk through the account deletion flow.
Working with the customer support department, I identified the top reasons why users delete their account. My intent was to collect more data but also to prevent deletions in some cases.
Authorization holds are a key reason for account deletion, but mostly because users don’t realize the hold is released after a period of time. This content resulted in a ~10% save rate.
I helped ensure a legal-requested option for “none of the above” was included in the flow.
This isn’t a heuristic in many account deletion flows that I’ve seen, but it was a concession I made with the legal team in an overabundance of caution.
Now, let’s look at the flow for downloading a user’s data.
This email confirmation screen errs on the side of redundancy in the interest of privacy and account integrity.
When the user’s data is ready, Lyft sends an email letting them know to re-enter the privacy portal to download their info.
Here’s the final screen for the data download flow. Because a user’s data will change from the time since request to the time of receipt, we included another CTA for requesting so users would continue to have full access to their data.
Outcomes
By being flexible as a design squad, we were able to move in a lightweight way that enabled the team to deliver the finished products far in advance of the deadline.
Having that extra time let us test iterations and improve the CX, leading to a ~10% save of accounts from users looking for other information, not truly intending to delete their account.