01Context

Role: Senior UX Designer & Strategist

Team: 8-person cross-functional · product, engineering, policy, compliance

Scope: Mobile app + responsive web · iOS · Android

Agency: Social Security Administration (SSA)

Timeline: 2023–2024

What the App Was Supposed to Do

SSI recipients are required to report monthly wages to the Social Security Administration. The existing process was paper-based and phone-dependent — 35+ minutes per call, no confirmation receipt, processing delays that generated overpayments and incorrect benefit calculations. The app's job was simple: make wage reporting something people could do in five minutes on their phone.

The app existed. It worked. And it had no multi-factor authentication.

The Compliance Gap

Federal identity and authentication mandates — NIST SP 800-63B, OMB M-22-09 — required MFA for any system handling benefit or financial data. The wage reporting app was out of compliance. That gap had to close.

Methods

Tools

02Challenge

Two Things That Can't Both Win — Until They Do

The core tension wasn't technical. Stakeholders were convinced that adding MFA would trigger the exact failure mode the app was built to prevent: users abandoning digital reporting and going back to the phone. They saw security as the enemy of adoption.

That framing was wrong, but it was grounded in a real pattern. Federal apps that bolt on authentication as an afterthought see drop-off. The question wasn't whether MFA creates friction — it does. The question was whether the friction had to feel adversarial.

What Had to Be True for This to Work

Why This Was Hard

The user base made every design decision higher stakes. SSI recipients skew older, lower-income, less digitally literate. Many are smartphone-only. Many have accessibility needs — screen readers, motor disabilities, vision loss. An MFA flow that works for a tech-comfortable user can completely break for someone who doesn't know what a one-time passcode is.

The design had to work for the hardest user, or it didn't work at all.

03Users & Constraints

I synthesized federal data from the FCC, NTIA, GAO, and Pew Research to map the real access landscape for SSA's beneficiary population. Understanding who was actually using this app — and on what — shaped every design decision.

Who's Reporting Wages

Persona distribution across four primary user segments · Click to view full size

Key Constraints

• Legacy Mainframe Integration: Wage data housed in COBOL systems with limited API surface. Authentication strategy had to work within existing backend architecture.
• Authentication Fragmentation: Multiple identity pathways existed — ID.me, Login.gov, SSA-native — with inconsistent mobile support. A unified approach was required.
• Government Procurement Timeline: Multi-year approval cycles. Security and policy review add significant runway. UX strategy had to account for phased implementation.
• Accessibility Debt: Existing SSA digital services had mixed WCAG conformance. No shared component library. This was an opportunity to establish the right patterns from the start.

04Approach

Research That Grounded the Strategy

Before touching wireframes, I needed to understand what comparable federal apps got right and wrong with authentication — and what the data actually said about this population's device and connectivity constraints.

Five Insights That Shaped the MFA Design

• Authentication language is a failure point before authentication is: Users fail MFA because they don't understand what they're being asked to do — not because the flow is technically broken. Plain language was a security requirement, not a UX nicety.
• SMS OTP is the only universal option: Authenticator apps require installation and comfort with a new tool. Backup codes require storage. For this population, SMS was the only option that didn't add a prerequisite task.
• Trust signals had to precede the auth ask: Springing a verification screen on users who don't expect it reads as suspicious. The MFA prompt needed to be framed, contextualized, and placed where it felt expected — not random.
• Cognitive load was already high before the auth step: Users coming to report wages are dealing with deadline pressure, benefit anxiety, and often limited digital confidence. MFA had to minimize new decisions.
• Recovery paths couldn't require a desktop: Phone-only users who get locked out have no alternative device for account recovery. Every failure state needed a mobile-complete resolution path.

Research synthesis · Population segments, device access, and authentication failure modes · Click to view full size

Four Design Principles

These governed every subsequent decision — authentication flow, form architecture, error states, and recovery paths.

05Solutions & Design

The MFA Flow: Designed to Feel Expected

The authentication flow was built on Login.gov's identity infrastructure with a purpose-designed wrapper for the wage reporting context. The goal: users should feel like verification is a natural part of the process — not a checkpoint they didn't expect.

Before & After: Legacy Process vs. New Flow

Redesigned flow reduces completion time from 35+ minutes to ~5 minutes, with 24/7 availability and immediate confirmation.

Authentication Flow Architecture

Wage reporting and password recovery flow · Login.gov MFA integration, error recovery paths, and offline states · Click to view full size

Wireframe Flow: 14-Screen Mobile Architecture

14-screen mobile flow · MFA authentication through wage submission · Click to open interactive slideshow

State Model: What the System Communicates at Every Step

A clear state model was required for every screen the user encounters — especially auth states, which are the highest-anxiety moments in the flow. Ambiguity at an auth screen reads as the app breaking.

Complete state model · Authentication through submission, including error and offline states · Click to view full size

Trust, Transparency & Compliance

Trust and transparency pattern matrix · Data disclosure, error prevention, and accessibility standards across the flow · Click to view full size

Constraints Diagram

Constraint map · Accessibility, compliance, legacy systems, and operational requirements in tension · Click to view full size

06Outcomes

Compliance Met. Adoption Preserved. Stakeholder Concern Resolved.

The strategy and design artifacts advanced the wage reporting app to prototype validation. Research was adopted as the foundation for SSA's mobile product roadmap. The MFA implementation addressed the compliance gap without triggering the adoption collapse stakeholders had anticipated.

What This Produced

AI Roadmap: What Comes Next

The wage reporting system has a clear path toward intelligent assistance — form guidance, proactive error prevention, accessibility enhancements, and predictive support for high-risk reporting periods.

AI enhancement roadmap · Intelligent assistance, proactive validation, and predictive support · Click to view full size

07Reflection

The Real Design Problem Was a Framing Problem

"The hardest part of this project wasn't the MFA flow. It was making stakeholders understand that MFA doesn't have to feel like punishment. If it does, that's a design failure, not a compliance requirement."

Key Decisions and Reasoning

Login.gov over SSA-native auth: Login.gov already had mobile-optimized MFA flows, accessible component libraries, and established user trust in the federal context. Building SSA-native would have reinvented infrastructure that already existed and passed compliance review. Leverage what works.

SMS OTP as primary, not biometric: Biometric authentication is faster and lower-friction for users who have it. But biometrics require device capability and user setup. For a population where many are on older prepaid devices, SMS was the only option with universal reach. Design for the hardest case first.

Contextual framing before every auth step: One sentence of explanation — "We need to verify it's you before you submit your wages" — consistently tested as the difference between users continuing and users dropping. Security prompts without context read as the app malfunctioning. Context is a design component.

Keeping recovery paths mobile-complete: Every locked-account or expired-code state resolves on the phone. No desktop fallback. No field office visit. For smartphone-only users, that isn't a convenience — it's whether the recovery path exists at all.

What I'd Do Differently

The stakeholder resistance to MFA would have been shorter-lived if I'd led with comparable examples earlier — specifically federal apps that had navigated the same tension successfully. The research existed. The conversation about framing authentication as trust-building rather than friction could have happened weeks earlier than it did.

I'd also have pushed for a small-scale pilot test with the contextual framing variation before the broader prototype validation. The "verify it's you" sentence was discovered through usability testing; it could have been a hypothesis that entered the design earlier.

What This Project Shows

• Compliance and usability aren't opposites. The tension is real, but it's resolvable. The path through it is design, not compromise.
• Stakeholder resistance is design input. The fear of adoption collapse wasn't wrong — it was an accurate read of how bad MFA implementations perform. Listening to that fear produced a better design than ignoring it would have.
• Designing for the constrained user raises the bar for everyone. The plain-language prompts, single-question flows, and mobile-complete recovery paths that worked for the hardest user made the experience better for every user.
• Trust is a feature. In government services handling benefit data, the user's perception that the system is protecting them — not surveilling them — is as important as task completion. You have to design both.

→Interactive Prototypes

SSA Mobile Wage Reporting App Prototype

Two complete mobile prototypes demonstrating the end-to-end user journey — Login.gov MFA integration, password recovery, and the full wage reporting task flow.

• Password Recovery Flow: Handles forgotten credentials through email verification with fallback authentication options (SMS, authenticator app, backup codes). Includes real-time password validation and link expiration after 10 minutes.
• Wage Reporting App: Complete task flow from Login.gov authentication through 4-step wage entry — reporting type selection, paystub submission (photo upload or manual entry), and success confirmation with future reporting reminders.

Password: ENTER

Interactive prototype · Login.gov MFA through wage submission · Click to open in new window