Polaris Privacy Requests

One of the main requirements of the California Consumer Privacy Act is that businesses must honor its customers’ privacy requests for deleting, opting-out, and sharing their data.

Many larger companies have automated processes for this, but what’s a smaller business to do if it’s not feasible to automate?

 

Completed over the course of 3 months in 2021, in a cross-functional team consisting of a product manager, engineer, and me, the product designer.

Taking stock

When I came on in early 2021, Polaris had an existing tool to process privacy requests. Our initial plan was to essentially reskin and clean it up to match the new Get Compliant application, so the process would feel cohesive.

I began with a systematic UX audit of the request processing tool.

 
 

Request Inbox

This is where businesses manage their requests.

The text hierarchy is somewhat unclear; there’s a lot of information and it’s hard to know what to focus on.

As a sidenote, “Days overdue” is somewhat of an embarrassing stat to report; it’s technically illegal and TrueVault should be doing more to prevent it from happening.

 

Verification

Businesses are required to verify the consumer’s identity before they begin processing the request.

This screen is chaotic, to say the least. TrueVault’s instructions are in the pop-up window, and the business’s custom instructions are in the main screen.

How might we reduce the need for giant walls of text?

 

Processing

To process a Request to Delete, for example, a business has to delete all of the information it has about a consumer, and ask its vendors to do the same.

In Polaris, processing a Request to Delete involved:

  • making retain/delete decisions for each vendor

  • selecting a templated reply to send the customer

  • editing the template to insert specific delete exemption information.

Request Inbox

Redesign Priorities

  • Only show the metadata needed to identify a request and decide whether to act on it

  • Create a separate section for unverified requests (Pending)

  • Provide a clean, minimal view that’s focused on the requests themselves

 
 

Verification

There were several issues with verification:

  • It relied on a lengthy pop-up modal with instructions to guide users

  • Verification felt tacked-on; it was a critical step but was not really baked into the workflow

  • Businesses had to dream up their own verification method and document it

The original verification instructions. Yikes.

Verification instructions in context

 

✨ Automate it ✨

A business had to go through several verification steps before they could even begin to process a request.

  1. Send their custom verification instructions

  2. Wait for a response

  3. Confirm that the user had completed verification successfully

This felt like something that should be automated. I met with our legal team and determined we could use an email verification process that would happen before the business even saw the request. I redesigned the flow to support it.

Requests could now be processed in a systematic way without any back-and-forth needed between the requester and the business. We were moving toward a model of request -> final response rather than a messaging platform.

My goal was to require as little room for error when processing these requests; the process should be entirely on rails.

Three touchpoints reduced to one. Nice.

Processing a request

To process a Request to Delete—“Delete all of the information you have about me”—a business has to do several things:

  1. For each vendor, choose whether to delete or retain the requester’s data

  2. Delete all of the data the business has access to

  3. Contact the vendors and ask them to delete any remaining data

The existing UI for this consisted of a list of vendors, options to delete or retain, and a freeform text field for the business to add their deletion template.

 

Redesigned processing screen

The priorities here were:

  1. Have a clear step-by-step process

  2. Eliminate the need to make delete-retain decisions for each request—those are set once per-vendor in the Request Instructions

  3. Eliminate the need for custom templates. Once a business submits the request, it’s automatically closed and the email is sent to the consumer.

  4. Incorporate an additional legal requirement (Flow-down deletion)

Original page

Redesigned page

Next steps

Based on the feedback we’ve received so far, this is what we have planned next for request processing.

 

Custom templates

Our MVP prioritized processing requests as efficiently as possible, which meant deprioritizing custom messages. As we learn more about our customers’ unique use cases, we plan to allow some customization of the email templates and are investigating customizing individual messages as well.

Internal notes

Customers want the ability to leave their team internal notes on requests, particularly if more than one person is involved in processing or there is something unique about the requester that requires them to be processed differently.

Automate everything

Ideally, we would love to do all the heavy lifting ourselves of deleting the data and, at the very least, reaching out to vendors. The next steps are to remove as much of the processing burden as possible.