An exploratory study into SSA's mobile infrastructure — documenting the four hard constraints that responsive web couldn't solve, and the financial model that made native-first the only defensible recommendation.
Role: Senior UX Researcher & Strategist (Contractor)
Agency: Social Security Administration
Scope: Platform architecture · Infrastructure strategy · Accessibility · ROI modeling
Timeline: 2023–2025 · Multi-phase engagement
The Social Security Administration manages benefit relationships with over 70 million Americans — processing 6 million new applications annually across retirement, disability, and survivor programs. SSA.gov receives more than 500 million annual visits. It is one of the most-used government websites on the planet.
The platform was built for a different era. Form flows designed for desktop submission. Authentication systems predating biometric capabilities. Backend processing that takes days to confirm digital submissions. Between 70 and 85 percent of SSA digital interactions now originate from mobile devices. The infrastructure hadn't caught up.
This engagement was explicitly exploratory. The question wasn't "how do we build a mobile app?" It was: what kind of mobile infrastructure does an agency like SSA actually need — and what does the evidence say it will take to get there? That question surfaced four constraints that changed the entire direction of the recommendation.
The core question: How do you architect a mobile infrastructure for an agency serving 70+ million people — many with accessibility needs, limited connectivity, and low digital literacy — while navigating COBOL-era mainframe systems, federal security mandates, and a procurement process that moves at the speed of government?
Every abandoned digital session generates an estimated 3–5x operational cost compared to a completed online interaction. At 500 million annual visits, that math transforms a UX problem into a policy problem.
The engagement wasn't scoped as a feature request. It was designed to answer a structural question: could a responsive web strategy alone serve SSA's beneficiary base — or was native mobile a necessity?
I conducted a comprehensive audit of SSA's existing digital infrastructure, mapping dependencies between public-facing web services (my Social Security, iClaim, Wage Reporting), internal mainframe systems, and the Login.gov identity layer. That audit, combined with federal benchmarking and heuristic analysis, surfaced four constraints that responsive web couldn't solve by design.
30–35% of users abandon passwordless flows on current SSA mobile web.
Responsive web relies on browser-mediated biometric APIs that are inconsistent across devices, operating systems, and browser versions. Native apps access Face ID and fingerprint sensors directly through platform APIs — delivering reliable, low-friction authentication that browser-based flows cannot replicate at scale. Bank of America's native biometric rollout drove a 34% increase in mobile session initiation as friction-blocked users re-engaged. SSA's beneficiary base — older, many with limited digital fluency — needs that same reduction in authentication barrier.
Beneficiaries with intermittent connectivity cannot reliably complete multi-step applications in a browser.
Responsive web requires a live connection to persist session state. Native apps support robust offline data caching and draft persistence — users can start a wage report on a spotty connection, save progress locally, and sync when signal returns. SSA's beneficiary population skews toward rural households and lower-income users who are disproportionately represented in areas with unreliable connectivity. A strategy that leaves that population dependent on a stable internet connection isn't a viable federal modernization plan.
Deadline-driven and status-driven interactions require guaranteed delivery — browsers can't provide it.
Benefit status changes, document submission confirmations, reporting deadlines, and appointment reminders are not optional communications — they're legally and procedurally consequential. Browser-based push notifications require the browser to be running, depend on user permission grants that expire, and have no mechanism for escalation. Native push notification infrastructure delivers reliably, surfaces in the system lock screen, and supports read receipts. Users receiving at least one proactive notification per week show 40% higher 90-day retention than non-notified users.
WCAG 2.2 AA compliance at scale for 70M users demands native platform APIs — not cross-platform abstractions.
Adults 65+ represent 35%+ of SSA's beneficiary base. Many use screen readers, switch access, or other assistive technologies. Cross-platform frameworks — React Native, Flutter — introduce abstraction layers between the application and VoiceOver (iOS) or TalkBack (Android). That abstraction creates edge cases in custom components, gesture handling, and dynamic content that are difficult to test and harder to remediate. Native development gives engineers direct access to accessibility APIs, enabling the precision required to deliver WCAG 2.2 AA conformance across 25+ product lines serving millions of users with disabilities.
| Capability | Responsive Web | Native Mobile | Decision Weight |
|---|---|---|---|
| Biometric Auth | Browser-dependent, inconsistent | Direct platform API access | Critical — 30–35% abandonment at stake |
| Offline Support | Requires live connection | Full local caching + sync | High — rural/low-connectivity population |
| Push Notifications | Browser must be active | System-level, reliable delivery | High — deadline/status-driven tasks |
| Accessibility APIs | Abstracted, edge cases compound | Direct VoiceOver/TalkBack access | Critical — WCAG 2.2 AA mandate at scale |
| Performance | Cellular bandwidth dependent | Native rendering, optimized payloads | Moderate — 3s threshold abandonment |
| Development Cost | Lower initial cost | Higher upfront investment | Offset by ROI and lower long-term risk |
The strategic recommendation had to survive federal budget cycles and procurement review. That meant the analysis needed to be multi-layered: technical assessment of current infrastructure, benchmarking against peer agencies, heuristic evaluation with scored gap analysis, and a financial model grounded in real operational data.
I mapped SSA's existing infrastructure from presentation layer through data layer, identifying integration points, migration risks, and the surface area available for mobile-optimized services.
Proposed Mobile Infrastructure Architecture — Layered Service Model
The audit surfaced four structural constraints: COBOL mainframes with no RESTful mobile-optimized endpoints, fragmented identity verification pathways, 40+ WCAG violations across core flows, and infrastructure frequently breaching 3-second load thresholds at month-end traffic peaks.
I analyzed mobile strategies across peer agencies — VA, IRS, USCIS, and GSA — to identify patterns in platform choice, authentication integration, and accessibility implementation.
| Agency | Platform | Auth Method | Accessibility |
|---|---|---|---|
| VA Health | Native (iOS/Android) | ID.me + Biometric | WCAG 2.1 AA |
| IRS (IRS2Go) | Native | IRS-native | Mixed conformance |
| USCIS (myUSCIS) | Responsive Web | Login.gov | USWDS-based |
| GSA (Login.gov) | SDK/Integration | Login.gov | WCAG 2.1 AA |
| VA.gov (2017–2022) | Responsive + Native | ID.me + Login.gov | WCAG 2.2 AA (gold standard) |
VA.gov's modernization was the closest analog to SSA's challenge. Application-to-benefit time dropped 40%, digital-first resolution improved 35%, and ACSI satisfaction moved from 53 to 77 within four years. That transformation set the benchmark for what SSA's program could realistically deliver.
I applied Nielsen's 10 usability heuristics as a diagnostic framework, scoring SSA's current platform against three industry benchmarks: Amazon (search/navigation), MyChart (workflow completion), and Bank of America (security/trust).
Overall composite: SSA scored 5.1 against an industry benchmark average of 8.9. Platforms scoring 8+ show 35–55% higher task completion and 28–42% higher user satisfaction than low-compliance counterparts. The gap was the strategic mandate.
Session-level analysis of SSA.gov engagement revealed three critical drop-off points. Each maps to a distinct failure mode — and a targeted intervention.
| Funnel Stage | Drop-off Rate | Root Cause | Recovery Potential |
|---|---|---|---|
| Login → Search | 26% | Navigation architecture and search relevance failures | 8–12 pts via NLP search |
| Search → Form Start | 16% | Form length, jargon, unclear eligibility criteria | 8–12 pts via plain language |
| Form Start → Completion | 9% | No session-save, no inline validation, mid-form abandonment | Most recoverable stage |
| Total Recovery | 12–18 pts | Realistic conversion recovery with targeted interventions | |
The most impactful work on this engagement wasn't interface design. It was being in architecture meetings and reframing technical debates as citizen-outcome questions. Three decisions defined the strategic direction.
The recommendation included a set of mobile-first API design principles that would govern every new endpoint built for the native layer.
Lightweight JSON responses optimized for cellular bandwidth, with pagination and field selection support. No endpoint should return more data than a mobile screen can use.
APIs designed to return partial data rather than fail completely when backend systems are slow or unavailable. Critical at month-end traffic peaks.
API responses include semantic labels, ARIA hints, and localization keys — pushing accessibility into the data layer, not just the presentation layer.
Backward-compatible versioning to support older app versions. Essential for a user population that doesn't update applications promptly.
Rather than treating accessibility as a per-app concern, the recommendation called for a shared accessibility component library — a mobile-native equivalent of the U.S. Web Design System — enforcing WCAG 2.2 AA conformance at the component level across every SSA mobile product.
Why this mattered: Adults 65+ represent 35%+ of SSA's beneficiary base. The component library approach meant accessibility wasn't a retrofit — it was infrastructure. Every new product built on the library inherited compliance by default. Accessibility as a shared service, not a per-project line item.
The engagement produced a set of strategic and technical deliverables that shaped SSA's mobile infrastructure planning and directly influenced adjacent federal modernization programs.
The strategy required a financial case that could survive federal procurement and budget cycles. I built the ROI model from a composite of industry benchmarks, SSA baseline metrics, and analogous federal transformation outcomes. Responsive web alone — without native — left the four hard constraints unresolved and the ROI unrealized.
Projected impact: Full modernization would shift digital adoption from 40% to 65–70% of total service interactions — reallocating 125–150 million annual transactions to self-service digital channels and reducing per-transaction administrative cost from $1.40 to under $0.85.
This project made one thing concrete: infrastructure decisions are UX decisions. Every API design choice, every authentication architecture call, every platform selection has a direct and measurable impact on whether a person can complete a task, access a benefit, or trust a system. UX designers who stay at the surface layer — screens and flows — miss the most consequential design decisions, which happen in architecture meetings and technical review boards.
"What does this choice mean for someone on a prepaid phone in rural Mississippi who needs to report their wages by Friday?" That question, simple and concrete, reframed technical debates into user-centered decisions more effectively than any wireframe could.
The exploration mattered because the answer wasn't obvious going in. Responsive web is cheaper to build and easier to maintain. Had the audit returned a different finding — had the four constraints been solvable with progressive web app technologies or browser API improvements — the recommendation would have been different. The constraints weren't assumed. They were surfaced through analysis of SSA's actual user population, infrastructure state, and operational requirements.
Biometric abandonment at 30–35% isn't a preference problem. It's a system design problem with a measurable population consequence — beneficiaries who can't reliably authenticate don't get served digitally. Offline capability isn't a nice-to-have for a population that skews rural and lower-income. Push notification reliability matters when the communications are legally consequential and time-sensitive. Accessibility precision matters when 35%+ of your user base depends on assistive technology that breaks when abstraction layers misbehave.
Building the financial case: Federal modernization fails when it can't defend itself in budget cycles. Connecting heuristic gaps to call center volume to dollar costs — that translation work is what keeps programs funded through administration changes and competing priorities. Strategy without a number is a suggestion. Strategy with a number is a mandate.
Strangler fig over big bang: Recommending incremental migration over a full rearchitecture wasn't the path of least resistance — it was the only responsible path given SSA's scale and political risk tolerance. The USAJOBS failure validated that call.
The most effective moments on this engagement weren't when I was producing deliverables — they were when I was translating between technical constraints and human consequences. That positioning, between the people building the system and the people it was built for, is where strategy actually happens.
If I were to start again, I'd formalize the ROI modeling earlier — not as a final deliverable, but as a live framework running in parallel with the research. Decision-makers at SSA needed the financial case before they fully committed to the recommendations. Building it earlier would have shortened the alignment cycle significantly and given the exploration findings more weight in procurement conversations.