Shafeen Alam
Archive
AsurionStolen password checkMobile

Telling people when their passwords have been stolen

After a run of high-profile password breaches, Asurion wanted to give app users a way to check whether their passwords had ever been stolen. I designed two versions of the check, one that runs as each login is saved and one that scans everything weekly, with the goal of doubling the logins saved per user.

Role
Product Designer
Company
Asurion
Year
2017
Location
San Mateo, CA
case.md
$ cat outcome
kpi: 5 → 10 saved logins
status: no longer live
Why it mattered

People loved the idea of a password check, but did not believe it could be that easy.

60-second read

Problem

Asurion needed more engagement and more users. Breaches were in the news, and people were saving few logins in the app.

System decision

Two checks: one immediately after each login is saved, and a weekly scan of everything saved.

My contribution

User flows, prototypes from user stories, and usability and preference testing throughout.

Outcome

The KPI was 5 to 10 saved logins per user. The project is no longer live and I do not have data on whether it was met.

01 · Situation

Breaches were in the news, and the app needed a reason to be opened.

We needed to increase engagement with the app and gain more users. With password and data breaches making headlines, we thought a tool that let people check whether their passwords had ever been stolen would raise engagement and increase the number of passwords each person added. Our KPI was to move saved login records per user from 5 to 10.

02 · Obstacles

People wanted it, but did not trust that it could be simple.

In testing, people loved the idea of checking whether their login records had been stolen, but did not believe it was that easy to do. Separately, we were negotiating a contract with another company to run the stolen password check. That negotiation was blocking development of the feature, so we went another route.

03 · Action

Flows and prototypes from user stories, tested at every step.

I created user flows and prototypes from user stories, and ran usability and preference testing throughout the design process to check my decisions. Engineering had known limitations, so I shared the designs with the team as they developed to keep us aligned.

04 · Two approaches

Immediate check

Check a password as soon as each login record is added, so the answer arrives while the person is still in the moment.

Immediate check flow: new or existing user adds a login record, is asked to run a password check, and is sent to change the password or add another login
Ongoing check

A weekly scan of every saved login record, so a password that is stolen later still gets caught.

Ongoing check flow: from the app or a push notification, the user runs a scan, then sees stolen logins or weekly scan reminder settings

05 · Android

Android gave us root-level access to the phone, which iOS did not.

That let the Android app do more than the iOS one. It could work across other apps on the device, so the design covered more than the password check itself: the stolen and safe results, locking individual apps, and filling in logins inside other apps.

Android alert: your account password has been stolen
Stolen: change the password now.
Android alert: your account has not been compromised
Safe: add another login.
Android App Lock list with system and app toggles
App Lock for system functions and individual apps.
Android Smart Login setup through Accessibility settings
Smart Login setup through Accessibility settings.
Android auto-fill dialog over the Facebook login
Auto-fill offered over another app’s login.

06 · Where it ended

The project is no longer live in the App Store or Google Play. I do not have data showing whether we met the KPI of 10 saved logins per user, so I am not claiming a result here.

07 · What I learned

01How to structure research questions on UserTesting.com.
02How to run preference testing on UsabilityHub.
03How to record users better during guerrilla testing in coffee shops.
04How to review apps in TestFlight before they reach the app stores.
05How to work inside a larger organization.
06That a project can be shut down, or restarted, for reasons outside your control. Leave it in a state where someone can pick it back up.

I also spent time structuring the files and using symbols in Sketch so the app could be re-skinned quickly if one of our carriers wanted to move forward with the project.

Leave every project in a state someone can restart.

Next case studyCreator content & monetization platformRead the case study