LifeLock Alert Feature Enhancements

Project Context

Identity business generates over a billion dollars annually within the company. However, over the past 2 years, Identity retention declined 1% YoY each year. How to recover? We found dozens of issues focused around a few key themes such as login, transaction monitoring and alerts.
‍
Among these issues, optimizing the alert experience is expected to have a significant impact.

The Message was Loud and clear

Upon taking this task, my focus was on finding ways to enhance the current alert experience. What our members are saying?

"I couldn’t quickly find all my financial activity alerts on the app and had to use my laptop instead. I initially selected 'no,' but later realized it was my husband who made the transaction. How can I change my response, and where did the alert go?"

"I could not find my dark web monitoring alerts after read it. Not sure what should I do if my information is exposed?”

Design iterations

1.0

Review Alert List

User Goals - Find alert and act quickly

Whether on mobile or web, the primary route to view an alert is through alert list page. We currently don't have filters on the mobile app, however, web filters also have some usability issues that user may encounter. I started to analyze the existing web filters, aiming to assess its effectiveness and identify potential areas for improvement on both platforms.

Current Web Filter Problems

Leveraging Web Filter Analysis Learnings for Mobile App New Design

PAIN POINTS

Time consuming to find a specific category of alert;
The current list is an infinite scroll that includes all historical alerts. Listing everything under “New Alerts” is confusing;
New users had difficulty quickly understanding the visual cue difference between read and unread alerts;
Alert body takes up a lot of space, which adds more scrolling;

BEFORE

AFTER

DESIGN RATIONALE

Added unread alerts count in Inbox;
Introduced filters to help user quickly find specific alerts;
Removed the “New Alerts” text and referenced best practice to visually differentiate read and unread alerts;
Limited the header and body text to within two lines to save space and reduce scrolling for users;
Introduced flagging functionality to help users remind themselves;

Filter Solution Examples

The general idea was to streamline the filter options by incorporating the most helpful categories, while preserving flexibility for customization to serve a broader range of user needs.

All ALERTS

All CATEGORIES

All TIME

ALL MEMBERS

Iterations

I will use the "All Time" filter as an example to walk through my iteration process. I presented two versions to the engineering team to assess feasibility and incorporated their feedback to develop the revised solution.

Version 1

The placement of filter chips within the sheet is inconsistent with the behavior of other filters.

The wheel-style date picker is typically used when space is constrained, and transitioning it on top of the sheet causes additional implementation efforts.

Version 2

When the user taps the date button, the date picker opens in a modal view. Having one overlap on top of another is not ideal for the user.

There are too many clicks required for users.

Selected Version 3

Present the date picker directly to the user and pre-select a date for them, eliminating the need to open another page or modal.

This approach saves two clicks from version 2 and allows users to modify the date on the same screen.

2.0

Review Details Page

User Goals - Understand alert details and interact accordingly

As mentioned earlier, the top 3 volume alerts coincidentally represent 3 different types of alerts, each with different behaviors:

TYPE 1 - The Financial Activity Alert is a basic disposition type alert, where users can respond with "Yes" or "No" on the detail page to confirm the transaction.
TYPE 2 - The Credit Inquiry Alert is an advanced disposition type alert, where we ask follow-up questions if the user does not recognize the activity.
TYPE 3 - The Dark Web Monitoring Notification is currently read-only and will automatically be archived after the user reads the notification.

Type 1 & 2 Alert Details

On the detailed page, the first two types of detail pages are well understood by our users overall. Therefore, without making significant changes, I decided to only reduce the red header real estate to allow users to focus more on the details and standardize the copy for each section across all pages for better consistency.

TYPE 1 - BEFORE

TYPE 1 - AFTER

TYPE 2 - BEFORE

TYPE 2 - AFTER

Type 3 Details

However, our member service team received numerous confused calls regarding these notifications. Users want a comprehensive explanation of the incident, including when the breach occurred, how it happened, and what steps they should take in response. Some of them even assume that LifeLock is responsible for deleting or securing their exposed information.
‍
With our current lengthy scrolling details page, addressing these pain points is a little challenging.

PAIN POINTS

Lengthy scrolling, lacks information hierarchy, hard to digest and focus on the actions that need taken;
The current "What can you do next?" section is too clunky and includes too many proactive steps that aren't relevant to the DWM alerts.
No interactions available like the other two types of alerts;
Members get confused when they tap the return button and their focus shifts to the archive folder, as they are not aware of the auto-archiving process.

BEFORE

AFTER

DESIGN RATIONALE

Broke content into smaller sections and collapsed "Why you received this" to improve information hierarchy and reduce scrolling.
Added "Exposure Date" to provide more context for users.
Added "What to do now" to address users' most pressing concerns, providing customized tips depends on the exposed category. Reiterate that neither we nor the user can remove data from the dark web.
Stopped auto-archiving by introducing a CTA that encourages users to move the alert to Archive once they’ve noted all the steps.
All tested users appreciated this section, mentioning that it was clear enough that they wouldn’t need to contact customer support.

3.0

Receive Confirmation

User Goals - Understand where are alerts all the time

Based on insights from user testing, we learned that users are often confused about where to find alerts they've previously responded to because we haven't clearly communicated how we help them manage alerts.

Since Type 3 read-only notifications currently lack CTAs and confirmation page, I will primarily focus on presenting the disposition pages for the other two types and discuss how I addressed the related challenges for all three.

Current Problems - When Responded Yes

TYPE 1

TYPE 2

PAIN POINTS

When user responded with "Yes", we move both Type 1 and Type 2 alerts to the Archive folder, but we never communicate to the user.
For Type 2 alerts, when users expand the "If you need additional help" section, the message starts with "If you believe this activity may have been fraudulent", which threw people off and left many users feeling very confused.

Current Problems - When Responded No

TYPE 1

TYPE 2

PAIN POINTS

User often struggle to find the alert later because they don’t know where it was moved.
For Type 1 alerts, even when user respond with "No", we still move it to the archive folder. This is not only confusing but also hard for user to find to follow up.
For Type 2 alerts, if user requested LifeLock to investigate the alert, many of them ended up tapping "If you need additional help" afterward. However, we start with "If you believe this activity was NOT fraudulent", which ends up being misleading and confusing for users, leading to a significant increase in customer service calls.
Details section is collapsed by default on the confirmation screen, one more tap for user if they are calling for help.

Iterations

After analyzing the current pain points, I believe we should not only clearly communicate how alerts are organized among the three folders but also reconsider whether the current organizing logic makes sense and how to make it more straightforward for users.

I collaborated with our user researcher, conducted three rounds of user testing, gathered valuable insights, and kept iterating until we arrived at the optimal solution.

CURRENT

For Type 1 alerts, moving "Yes" and "No" responses to the archive folder doesn't help users find alerts that need their attention.

For Type 2 alerts, we currently move them to the disputed folder if the user responds with "No". This moving behavior makes sense since it's a more severe type of alert, prompting our agents to investigate the activity and initiate identity restoration services if needed.

For Type 3 alerts, there is no interaction for user to take, users also have hard time to find it to follow up;

ITERATION 1

All individuals observed the inclusion of CTAs in all alerts.

The Archive functionality was universally understood; users recognized that once they had taken the necessary actions for an alert.

However, there was a lack of clarity for some users regarding the intended function of the Follow-up button.

Yes/No question doesn't really apply to Type 3 alerts.

ITERATION 2

Users appreciated the new auto-flag function for Type 1 alerts after responding with "No".

They expressed a desire for the ability to flag all types of alerts.

However, when users return to the list and accidentally unflag the alert, it's confusing to see it revert to the original Yes/No state when opened again, since they've already provided their disposition.

User understands that they need to take action by themselves after reviewing the “What to do now” copy.

REVISED SOLUTION

Users appreciated that we auto-mark Type 1 alerts if they responded with "No".

They like the capability to flag/uflag all the alerts, many users mentioned that this resonates with their email inbox.

When they return to the list, they can tell the difference between flag and attention required icon, as one is user-triggered and the other is LifeLock-initiated for them.

All tested users appreciated "What to do now" section, mentioning that it was clear enough that they wouldn’t need to contact customer support.

Revised Solution - When Responed Yes/Move to Archive

After we settled down with the revised logic, I started to templatize the confirmation screen so users always have a clear understanding of how we help them organize alerts.

The first card always informs users where alerts are moved after they provide their response.
For Type 1 financial activity alerts, we provided a link for users to revert their disposition if they recognize the activity, as it may have been done by a family member. This helps reduce false positive scenarios and alleviate pressure on the customer service team.

TYPE 1

TYPE 2

TYPE 3

Revised Solution - When Responded No

For Type 1 alerts, if user responded No, we auto-mark them in case they need to revisit later. This "attention requested" mark prevents false positives that might occur if users accidentally unflag alerts. Users appreciate this approach as it ensures they don’t miss important alerts.
On the "No" confirmation screen, I decided to expand the "Details" section by default so users have the information readily available in case they need to contact institutions.
The "What to do now" section always sticks to the bottom to help users if they do not recognize the activity. During user testing, users really appreciated that I added the contact number to the instructions, saving them the effort of searching for the institution's contact.
All the copy has been streamlined to provide clear guidance for users.

TYPE 1

TYPE 2

TYPE 3

Reflection & Next steps

This project has faced several challenges, it was paused twice—first because our original PM left, and then due to a company reorganization and priority changes. I was the only main stakeholder left on this project for a while.
Despite all the setbacks, I still believed in the potential to improve this crucial LifeLock feature, so I continued presenting different solutions to the product team. Luckily, we were eventually able to restart the project.
This process involves many alerts—currently about 130 types. Categorizing them into three flows and templatizing the details and disposition page simplifies implementation for engineers.
We are currently implementing the MVP design. Since we introduced new CTAs to Dark Web Monitoring, we will monitor its performance closely and may provide different recommendations based on what information is leaked in the post MVP.

Want to work together?