Identity Guard iOS / Android
Roles I Lead UX/UI, Shaped Product Vision & Roadmap
[Note: I designed the original app. The Identity Guard app currently available – as of 8/25/2020 – has been 'updated' and has a low rating due to bugs and UX issues. Reviews for the Identity Guard apps (iOS/Android) two years ago were positive (4+ stars).]
Personal Identity protection in the palm of the hand. The mobile experience was focused on alerts delivery and management as well as personal information entry: new credit cards, account numbers, etc.
Our research showed that alert response time was critical in successful mitigation of risk. Once a credit card was hacked, the clock was ticking. The mobile experience was critical in delivering on that promise.
The business objective was to have the web and mobile experiences released in four months from start of development. That was all-inclusive: research, exploration, information architecture, interaction design, visual design, development and QA in four months.
Our only insights at the time were based on two sources: demographic data gleaned from a legacy product and a Kano chart of potential product features, the result of a study conducted by an outside agency.
From these we took what we could: we knew our audience skewed older, and from there we could derive some assumptions about device usage and preference, and consumption habits. We also had some justification for feature prioritization.
Information Architecture and Work Flow
We needed a structure and nomenclature that could evolve as the product experience evolved and the architecture needed to work on mobile, tablet and desktop. For MVP, we decided to push ahead in the spirit of Agile development and gather user feedback from production.
I settled on two main organizational concepts: inputs and outputs, or in the Identity Guard vernacular, Watchlists and Alerts. Anything the user wanted us to monitor (an input) would be captured in the Watchlist section. An input could be a social security number, a credit card, a child, a credit score. An output would be any alert triggered by an input. If a credit score dipped below a certain point, we'd generate an alert. If a social security number was found on the Dark Web, we'd generate an alert. The system was simple and could expand to accommodate all manner of inputs (tags, numbers, other people, social media accounts, etc.) Outputs were alerts with four stages of severity, and which all shared a common form factor.
Given the need to move into development ASAP, I was worried about the information architecture. We needed a structure and nomenclature that could evolve as the product experience evolved. At the time we had to define the IA, very little of the experience was known. We also needed the basic architecture to work on mobile as well as on a desktop or tablet browser. Testing would have helped but our time was limited. For MVP, we decided to push ahead, gather user feedback from production, and fine tune the experience from there. (Agile!)