To download the PDF, click here.

SSA Mobile Wage Reporting App — Case Study

Role: Senior UX Designer & Strategist  |  Agency: Social Security Administration  |  Timeline: 2023–2024

01 Overview

The Social Security Administration (SSA) serves over 70 million beneficiaries — many of whom depend on mobile devices as their primary means of accessing government services. The Mobile Wage Reporting App was conceived to allow Supplemental Security Income (SSI) recipients to report monthly wages directly from their smartphones, replacing a paper-based and phone-dependent process that created delays, errors, and overpayments costing the agency billions annually.

I led the UX research and design strategy for this initiative, working within a cross-functional team of product managers, developers, policy analysts, and accessibility specialists. The goal was to deliver a human-centered, accessible mobile experience that reduced reporting friction while maintaining compliance with federal security and accessibility mandates.

The core challenge: How do you design a wage reporting tool for a population that skews older, lower-income, less digitally literate, and disproportionately reliant on smartphones with limited data plans — while meeting Section 508, WCAG 2.2, and federal security requirements?

02 Research & Discovery

Landscape Analysis

I began with a comparative UX analysis of existing mobile applications in adjacent domains — Amazon, MyChart, VA Health, and IRS2Go — evaluating each against Nielsen Norman Group heuristics, WCAG 2.2 conformance, and emerging paradigms like AI-assisted navigation and adaptive personalization. This surfaced industry patterns in authentication flows, task-state-adaptive interfaces, cross-platform continuity, and progressive disclosure — all directly applicable to SSA's mobile context.

Underserved Population Research

I conducted a federal data synthesis drawing from the FCC, NTIA, GAO, NIH, and Pew Research Center to map the broadband and mobile access landscape for SSA's target users. Key findings included:

27%
Smartphone-only users (low income)
40%+
Form abandonment in similar services
70M+
SSA beneficiaries served
508
Section compliance required

Stakeholder & SME Interviews

I facilitated structured interviews with SSA field office staff, policy experts, IT security leads, and third-party advocacy organizations. These sessions surfaced operational constraints (e.g., legacy mainframe integration requirements), institutional risk tolerance, and real-world beneficiary pain points that wouldn't appear in quantitative data alone.

03 Design Strategy

Guiding Principles

Based on the research findings, I established four design principles that governed all subsequent design decisions:

  1. Simplicity over comprehensiveness: Reduce the wage reporting flow to its minimum viable steps — no ancillary features in the MVP.
  2. Accessible by default: WCAG 2.2 AA conformance baked into every component, not bolted on after development.
  3. Trust through transparency: Plain-language confirmation screens, visible data handling disclosures, and clear error recovery paths.
  4. Offline resilience: Draft-and-save capability to accommodate unreliable connectivity.

Phased Delivery Approach

Phase 1 — Core Reporting MVP

Single-task wage reporting flow with Login.gov authentication, plain-language UI, and confirmation receipt.

Phase 2 — Enhanced Feedback

Status tracking, push notifications for reporting windows, and income history dashboard.

Phase 3 — Adaptive Features

AI-assisted wage estimation, document upload via camera, multilingual support, and cross-device continuity.

04 Key Decisions & Tradeoffs

Authentication: Login.gov vs. Custom

SSA had considered building a proprietary authentication layer. I advocated for Login.gov integration, despite its limitations with prepaid phone MFA, because it reduced development scope, aligned with federal identity standards, and leveraged an existing trust relationship with beneficiaries. The tradeoff was that some users would need field office support for initial enrollment — we addressed this by designing a guided onboarding experience with clear escalation paths.

Native App vs. Progressive Web App

I recommended a native mobile application over a PWA for the MVP. While PWAs offer faster deployment, native apps provided better biometric authentication support, more reliable push notifications, and superior offline storage — all critical for this user population. The phased roadmap included responsive web parity in Phase 2.

Form Design: One Screen per Question

The wage reporting form was designed as a single-question-per-screen flow rather than a consolidated form. Usability research consistently shows that step-by-step flows reduce cognitive load and error rates for users with lower digital literacy — even though it increases the total number of screens. Each step included contextual help text, input validation, and the ability to navigate backward without data loss.

05 Outcomes & Recommendations

The research and strategy phase produced a comprehensive set of deliverables that informed SSA's product roadmap and procurement decisions:

Impact: The strategy and research artifacts produced during this engagement were adopted as the foundation for SSA's mobile product roadmap. The wage reporting app concept was advanced to prototype validation, and the underserved-population research was cited in internal policy discussions regarding digital equity and service delivery modernization.

06 Reflection

This project reinforced a core conviction: accessible design is not a compliance checkbox — it's a design philosophy. The users we were designing for didn't need a "dumbed-down" experience; they needed an experience that respected their constraints without patronizing their intelligence. Every design decision — from authentication flow to form structure to offline capability — was a choice about who gets included and who gets left behind.

Working within the federal space also sharpened my ability to navigate institutional complexity. Good UX in government requires more than good design artifacts — it requires building consensus across policy, security, IT, and operations stakeholders who each bring legitimate but sometimes competing concerns. The designer's role in that context is part translator, part advocate, and part strategist.