Customer Authentication
A federal mandate doesn't negotiate on deadlines. In 2024, the FCC required AT&T to close the authentication gaps behind SIM-swap and account-takeover fraud — and I was the only UX designer responsible for rebuilding how Customer Connect verifies identity, across every account type, device state, and channel it touches.
The Problem
One mandate, four variables: wireless vs. unified accounts, authenticated vs. unauthenticated handsets, four channels, and every way authentication can fail. No fallback could rely on data a bad actor could guess or buy.
The riskiest edge case — a cancelled account, reached offline or through IVR, with none of the usual identity signals available — had no real path before this project.
My Role
I was the sole UX designer assigned to this initiative — no dedicated design lead on it, no second designer to divide the account-type and channel combinations with. I worked directly with content design on system language and with identity and backend engineering on what was actually enforceable server-side, but the failure-state mapping, flow architecture, and trade-off decisions were mine to make.
The Model
Passcode first, OTP-to-email on failure, capped attempts before routing to retail — applied consistently across every account and device state.
We deliberately chose not to surface a live failed-attempt counter — handled as standard backend behavior rather than a visible threshold an attacker could work against.
FCC L0 — [caption]
Waterfall Authentication — [caption]
Owning Every Failure State
Before I designed a single error screen, I mapped every state the authentication flow could enter on my own — sent, shown, consent allowed or denied, authentication success or failure, authorization granted or denied, timed out. Nobody assigned me that map; half of those states didn't have a UX owner until I claimed them. Success was the easy screen. These weren't — and some, like passcode reset, had to ship twice: once for wireless accounts, then again, separately, for unified accounts.
Authentication State Map — [caption]
Push Notification Errors — [caption]
Failed Passcode Attempts — [caption]
Passcode Reset — IVR, Handset Authenticated — [caption]
FCC Cancelled Accounts — [caption]
One Model, Every Channel
Call center, retail, and chat each have different constraints — different latency, different UI real estate, different teams owning the surface. The authentication logic stayed identical across all three; only its expression changed. The Sprinklr integration below is the clearest proof: two authentication systems collapsed into one login for the customer, after years of contract and integration hurdles other teams hadn't been able to clear.
OTP — Chat Interim Solution — [caption]
FCC Chat — [caption]
Seamless Integration — Sprinklr + ACC — [caption]
Impact
- Replaced a per-channel, per-account-type patchwork with one waterfall model — covering the previously unhandled cancelled-account case for the first time.
- Independently mapped and designed for every failure state in the authentication flow — denied consent, timeout, exceeded attempts, unverifiable email — before any of them had a UX owner.
- Aligned unique dev requirements across six applications inside a fixed federal deadline; the first mandated release passed pre-launch verification with zero defects, and business stakeholders called it one of the fastest release-to-production turnarounds they'd seen.
- The redesigned authorization flow was processing authentication events in the millions within days of launch — under compliance, legal, and AVP-level sign-off on every release.
Fraud and account-takeover metrics aren't mine to disclose. What's shown here is delivery scope, system volume, defect rate, and sign-off level.
Reflection
Compliance work is graded on what you forgot, not what you shipped. This project taught me to design the whole state machine up front — not just the path I hoped the customer would take.