Role: Senior UX Designer & Strategist | Agency: Social Security Administration | Timeline: 2023–2025
As the Social Security Administration prepared to launch its first native mobile application, a foundational question needed to be answered first: What does SSA's mobile infrastructure need to look like to support not just one app, but an entire ecosystem of mobile-delivered services over the next decade?
I led the UX research and strategic analysis that informed SSA's mobile infrastructure decisions — from platform architecture and API design to accessibility frameworks and deployment models. This wasn't a visual design exercise; it was systems-level UX thinking applied to the technical and organizational foundations that would determine whether SSA's mobile future succeeded or failed.
The core challenge: 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 legacy mainframe systems, federal security mandates, and a procurement process that moves at the speed of government?
I conducted a comprehensive audit of SSA's existing digital infrastructure, mapping the dependencies between public-facing web services (my Social Security, iClaim, Wage Reporting), internal mainframe systems, and the Login.gov identity layer. This revealed critical constraints:
Proposed Mobile Infrastructure Architecture — Layered Service Model
I analyzed mobile strategies across peer federal agencies — the VA, IRS, USCIS, and GSA — to identify patterns in platform choice, authentication integration, accessibility implementation, and release cadence. Key insights:
| 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 |
Infrastructure decisions have UX consequences. I mapped the relationship between technical architecture choices and their downstream impact on user experience across five dimensions: performance (load times, responsiveness), reliability (offline access, error handling), accessibility (screen reader support, input flexibility), security (authentication friction, data visibility), and trust (transparency, data control). This framework ensured that infrastructure conversations stayed grounded in user outcomes.
I recommended a dual-track approach: native mobile applications for high-frequency, task-specific workflows (wage reporting, benefit status checks) paired with a responsive web experience for informational and lower-frequency interactions. The rationale centered on three factors:
The mobile API layer needed to serve as a translation layer between modern mobile clients and legacy backend systems. I proposed a set of guiding principles:
Rather than treating accessibility as a per-app concern, I recommended building a shared accessibility component library — a mobile-native equivalent of the U.S. Web Design System (USWDS) — that would enforce WCAG 2.2 AA conformance at the component level. This included:
The most consequential infrastructure decision was authentication. SSA had three options: build a proprietary identity layer, integrate Login.gov exclusively, or adopt a hybrid approach using Login.gov for initial identity proofing with biometric session management for subsequent logins. I recommended the hybrid approach — it reduced first-use friction while maintaining federal identity standards, and it created a path toward passwordless authentication as biometric technology matures.
SSA's existing architecture was monolithic. A full microservices migration would have been a multi-year, high-risk initiative. I recommended a "strangler fig" pattern: build new mobile-facing services as independent microservices while wrapping legacy mainframe calls in adapter services. This de-risked the migration, allowed incremental delivery, and maintained stability for existing web services during the transition.
I evaluated React Native, Flutter, and fully native (Swift/Kotlin) development for SSA's mobile apps. My recommendation was native development for the MVP, despite the higher upfront cost. The reasoning: SSA's accessibility requirements demanded pixel-level control over platform-native accessibility APIs (VoiceOver, TalkBack), and cross-platform frameworks still introduce abstraction layers that complicate accessibility testing and edge-case handling. The roadmap included reevaluation of cross-platform options as those frameworks mature.
This engagement produced a set of strategic and technical deliverables that shaped SSA's mobile infrastructure planning:
Impact: The infrastructure strategy became the foundation for SSA's mobile technology investment decisions. The accessibility component library specification was cited as a model for other federal agencies exploring mobile-native USWDS equivalents. The hybrid authentication recommendation directly influenced SSA's identity modernization roadmap.
This project taught me that infrastructure is user experience. Every API design choice, every authentication architecture decision, 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 are often made in architecture meetings and technical review boards.
The work also reinforced the value of translating between technical and human contexts. I was most effective in this engagement not when I was designing interfaces, but when I was sitting in rooms with engineers and architects and asking, "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, concrete, human — reframed technical debates into user-centered decisions more effectively than any wireframe could.