Stop Blaming Users for Dropping Off. The System Forgot to Ask Who Was Actually Using It.

Stop Blaming Users for Dropping Off. The System Forgot to Ask Who Was Actually Using It.

What a federal wage reporting app taught me about designing for systems that weren’t built with users in mind

Full case study and prototype at end of the article

There’s a class of design problem that doesn’t photograph well for a portfolio. Nobody’s delighted. Nobody’s discovering a feature they didn’t know they needed. The win, if you get one, looks like: the thing that was supposed to break didn’t break.

The SSA Mobile Wage Reporting project was that kind of problem.

Supplemental Security Income recipients are required to report their wages to the Social Security Administration every month. Not quarterly. Not annually. Every month. Miss a report, report late, or report incorrectly, and the agency generates an overpayment that it will eventually come to collect. For someone living on SSI benefits, that’s not an administrative inconvenience. That’s a financial crisis arriving with a government letterhead.

The existing process required a phone call to a 1–800 number — thirty-five minutes on average, no confirmation receipt, no real-time status, and a human processing lag that created overpayments before anyone realized a mistake had been made. The mobile app was meant to fix that. Report your wages in five minutes, on your phone, with a confirmation number. Simple premise.

Then came the compliance gap.

Federal mandates — NIST SP 800–63B, OMB M-22–09 — required multi-factor authentication (MFA) for any system handling benefit or personal identifiable information financial (PII) data. Scince it’s release in 2013, the wage reporting app had no MFA. That gap had to close, and closing it was non-negotiable. The question was whether closing it would destroy the thing it was protecting.

The fear wasn’t irrational

The product and operations teams were convinced MFA would tank adoption. Users would hit the verification wall, give up, and go back to calling in their wages…or trying to. Every gain the app had made would disappear. That fear wasn’t coming from nowhere — federal apps that bolt on authentication as an afterthought do see drop-off. The concern was grounded in a real pattern from comparable products.

But the framing was wrong in one specific way: it treated MFA as inherently adversarial. As if “friction” were a fixed property of the requirement rather than a consequence of how the requirement gets implemented.

That’s the framing problem I spent the first phase of the project trying to dismantle, not by dismissing the concern, but by separating the compliance requirement from the design choice. MFA doesn’t have to feel like punishment. If it does, that’s a design failure, not a mandate.

Who was actually using this app

Before touching wireframes, I needed an accurate picture of the user population, not an assumed one. I synthesized federal data from the FCC, NTIA, GAO, and Pew Research to map the real access landscape.

What came back wasn’t abstract. Twenty-seven percent of low-income adults are smartphone-only, no laptop, no tablet, no desktop fallback. SSI recipients skew older, many have cognitive or physical disabilities, and a significant portion are on prepaid plans with real limitations on SMS delivery reliability. Many had never encountered two-factor authentication. Some had Login.gov accounts they couldn’t access because the recovery email was an old address they no longer controlled.

That last detail matters more than it might seem. An MFA flow that locks someone out and tells them to recover via a desktop browser doesn’t have a recovery path for a large portion of this population. It has a dead end.

This population reframed every design decision. The constraint that drove the entire project was specific: the MFA experience had to be comprehensible to someone encountering two-factor authentication for the first time, on a prepaid smartphone, with a limited data plan, under the cognitive load of deadline pressure and benefit anxiety. If the design cleared that bar, it cleared every bar above it. If it didn’t, it didn’t matter how clean the interface looked.

Five findings that changed the design

The research produced a lot. Five things shaped the architecture directly.

Authentication language fails before authentication does. Users don’t abandon MFA flows because the technology is broken. They abandon because they don’t understand what they’re being asked to do. “Verification code” is jargon to a significant portion of this population. Plain language wasn’t a UX nicety, it was a security requirement, because a user who doesn’t complete authentication doesn’t get to report wages.

SMS is the only universal second factor for this population. Authenticator apps require installation, setup, and comfort with an unfamiliar tool. Backup codes require storage. For users on older prepaid devices, biometric options aren’t available. SMS was the only option with genuine reach — which meant it had to be the primary path, not a fallback.

Trust signals have to come before the authentication ask. An unexpected verification screen reads as suspicious. Users interpret it as the app breaking or as a phishing attempt. A single line of context , “We need to verify it’s you before you submit your wages”, tested consistently as the difference between users continuing and users abandoning. That sentence is a design component, not copy.

Cognitive load is already high before users reach the auth step. Someone coming to report wages is managing deadline pressure, benefit anxiety, and often limited digital confidence. The authentication flow couldn’t add decisions. It had to subtract them.

Recovery paths couldn’t require a desktop. Every locked-account or expired-code state had to resolve completely on the phone. For smartphone-only users, “visit your local field office” or “log in from a computer” isn’t an inconvenience, it’s the end of the task.

What the design actually solved

The MFA flow was built on Login.gov’s identity infrastructure, which already had mobile-optimized flows, accessible component libraries, and established user trust in the federal context. Building SSA-native authentication would have reinvented infrastructure that already existed and passed compliance review. The design work wasn’t about the authentication layer itself. It was about the wrapper around it.

Every MFA prompt was preceded by context. Single-question-per-screen architecture throughout — not because it looks clean, but because multi-field forms produce abandonment when users have limited digital literacy. Every failure state resolved on the device. Every error message explained the problem and provided the fix, not just a red border.

The state model covered every moment a user might encounter — verification pending, code entry, data review, submission, confirmation, and six categories of recoverable error. Ambiguity at an authentication screen reads as the app malfunctioning. Clarity at every state is a trust mechanism.

The result was a 14-screen mobile architecture that moved users from Login.gov authentication through wage submission in roughly five minutes, with a confirmation number at the end. The compliance requirement was met. The adoption concern — validated by prototype testing — didn’t materialize.

The cross-functional part

There’s a version of this project where the UX work stays inside the interface and hands off. I’ve seen that version of projects. It produces things that pass review and fail in the field.

What the SSA project required was presence in conversations that design is often excluded from, scope decisions, policy interpretation, prioritization calls. The stakeholder resistance to MFA wasn’t a communications problem to be managed. It was design input. The fear of adoption collapse was an accurate read of how poorly implemented authentication performs. Listening to it produced a better design than overriding it would have.

Converting that fear into alignment meant being able to speak in the language of risk and trade-offs, not just usability findings. It meant showing comparable federal implementations that had navigated the same tension. It meant connecting design decisions to operational realities, what the call centers could absorb, what a 40% abandonment reduction actually required at a structural level, not just a visual one.

Jeff Gothelf argues that UX strategy isn’t a separate layer from product strategy. He’s right. But that means UX practitioners have to be willing to work in that space, to show up in prioritization conversations with research that speaks to scope and sequencing, not just task completion rates. An insight sitting in a deck doesn’t change anything. The same insight surfaced at the right moment in a product decision can change what gets built.

What complex systems actually demand

This SSA project is a clean example of something that appears repeatedly in high-stakes design work: the complexity isn’t in the interface. The interface is often the simplest part.

The complexity is in the system the interface sits inside, the compliance mandate that can’t move, the legacy mainframe integration that constrains the API surface, the beneficiary population whose real capability range is nothing like the assumed user, the call-center dependency that means a bad mobile experience has downstream operational costs, and the organizational fear that has to be addressed before any design decision can be made.

Designing in that environment isn’t primarily about screens. It’s about mapping the system, actors and constraints, identifying where the real failure points are, sequencing decisions so the hardest problems get solved in the right order, and translating between user research, policy reality, and engineering constraint — in both directions, for different audiences.

That’s what complex systems design looks like from the inside. Not a methodology. A sustained orientation toward the full problem, held long enough to find the workable space between constraints that don’t move.

SSAMWR-MFA project didn’t prove that compliance and usability can coexist in “theory”. It produced a prototype that demonstrated it in practice. That’s the difference between design that argues its case and design that delivers in its work.

• Full case study
• Prototype (password = enter)