I was listening to Morning Edition on NPR a little while ago, and a story about the new Medicaid work requirements stuck with me. The reporting focused on young people and the administrative work involved: proving you work, proving your hours, proving you qualify for an exemption, and then doing it all again at renewal. What stayed with me was simple. Many of these people qualify, and the government often already holds the data to confirm it going forward. They can still lose their coverage, because the process is hard to finish.
That is the point. The system is designed to weed out “fraud and abuse,” and the friction is there on purpose. When people who qualify fall out along the way, the design accepts that loss as a cost.
I lead product teams, so I didn’t hear a political story. I heard a design built to reach a specific outcome, and it does that job beautifully.
Nobody Designs a Neutral Interface
In Nudge, Richard Thaler and Cass Sunstein make a point every product person should keep close: someone always decides the default, the number of steps, what gets asked first, and what happens when the user does nothing. They call that person a choice architect. If you build flows, you’re one, whether you meant to be or not. The question isn’t whether you’re nudging; it’s where you’re nudging people, and whether that direction matches the outcome you actually want.
Start with the company known for making buying easy, some would argue too easy. Amazon’s “Buy Now” button exists because someone spent years removing every step between wanting something and having it. Your address is saved; your card is saved; one click does the rest. Subscribe & Save reorders the dog food. Prime renews itself. Nobody asks you to prove you’re a real customer before each order. That is a completion-first design: every decision is made to help you finish.
Now try leaving. Most of us have clicked through several screens, been offered a discount, been routed to a phone number, or been told to chat with an agent, all to stop paying for something. The company knows exactly how to make things easy. It chose not to here. This is verification-first design, where the goal is no longer to help you finish but to make sure you really mean it. The newer edition of Nudge has a word for this: sludge. A nudge steers you toward a good outcome. Sludge makes a good outcome expensive in time, effort, and confusion. It usually works, which is why it sticks around.
Where Medicaid Fits
Medicaid’s new requirements are verification-first, and they put the friction in an unusual place: not only on the way in, but on the way to staying. The default is the opposite of Amazon’s. If you don’t finish the process, you’re out.
The early numbers show what that costs. Nebraska began enforcing work requirements on May 1, 2026. In the first four months, 7% of renewal applicants lost coverage for failing to meet the requirements or qualify for an exemption, and 14% of new applicants were denied. In Missouri, nearly 92 percent of the 333,000-plus people who lost coverage from January 2025 through February 2026 were dropped over paperwork, not because the state found them ineligible. In Arkansas in 2018, about 18,000 people lost coverage in nine months, and many of them should have been exempt.
Every product team knows this pattern. It’s procedural churn: users who qualify, removed because they couldn’t finish the process. In a business, that number gets tracked, named, and attacked.
What bothers me most is that the data often already exists. Federal law directs states to check the data they hold before asking anyone for anything. Wage records can verify employment, and other records can verify exemptions; the individual is supposed to be asked only when the data falls short. For someone who shows up cleanly in the data, that could mean verification without lifting a finger. Whether it does depends on whether each state has built the data matches to make it work. The gaps are real; many states are still building them, and manual verification is still expected for many people, especially the self-employed, informal workers, and family caregivers. The process could be easy for people who are easy to see in the data, and much harder for everyone else.
What a Product Review Would Flag
I’ve spent my career on the other side of this problem: figuring out why customers who should stay end up leaving. At Dash Logistics, aligning product and marketing strategy helped cut churn by 50%. The lesson that stuck is that churn almost never has one cause, and the first job is separating the people who left because they should have from the people who left because we made it hard.
If this process landed on my desk for review, these are the questions I’d want answered first:
- What is the goal? Is the system trying to get as many eligible people as possible to complete the process, or to verify that each person meets the requirement? These sound like the same goal, but they aren’t. A completion-first system asks how many eligible people we got through. A verification-first system asks how many people we confirmed. Every design choice that follows (the steps, the deadlines, the notices, the default) flows from which one you picked, and many teams never say it out loud.
- Who owns the metric? If one team is measured on verified compliance and nobody is measured on eligible people retained, the system will optimize for the first number every time.
- Where in the funnel are people dropping, and why? A person who no longer qualifies and a person who qualifies but missed a notice look identical in a headcount; they are not the same problem.
- What does a false denial cost versus a false approval? Every verification flow trades one against the other. Good product leadership makes that trade-off explicit and deliberate; bad design makes it by accident.
- What do we already know? Before asking a user for anything, ask what we can verify without them.
Those five questions turn “the process is hard” into a backlog, and the first one decides how the rest get answered. To see where the friction actually sits, I ran both kinds of design through the NUDGES mnemonic Thaler and Sunstein offer for good choice architecture, which doubles as a usability audit. Completion-first systems are built so people can finish; verification-first systems are built so the system can confirm. Both are legitimate goals, but they produce very different experiences, and the gap between them is where eligible people get lost.
[Insert infographic: The Friction Gap]
| UX pattern | Completion-first | Verification-first |
|---|---|---|
| Pre-filled data | You confirm what we already know | You re-enter it at every renewal |
| Steps | Short steps; ask only for what’s next | Long forms; everything up front |
| Save and resume | Progress follows you across devices | Sessions time out; progress is lost |
| Reminders | Email, text, and push; several touches | One mailed notice with a fixed deadline |
| Plain language | One clear button: “Renew” | Dense notices; hard to tell what to do or by when |
| Confirmation | Instant receipt and tracking | Unclear whether anything was received |
| Error prevention | Real-time validation | Mistakes surface weeks later |
| Recovery | Payment retry, grace period | A missed deadline ends coverage |
| Default | Stay unless you opt out | Out unless you prove you qualify |
The difference often comes down to a single sentence on the screen. Try trading “Submit proof of employment” for “We found your employer in state wage records; confirm to stay covered.” Or “Respond within 30 days or lose coverage” for “We have what we need; you’re all set until your next renewal.” Or “Your application is being processed” for “We received your documents on October 3; here’s what happens next.” None of these change who qualifies. They change who gets through.
This is where I come back to the Naive Question: “If we weren’t already doing it this way, is this the way we would start?” If we were designing verification from scratch, knowing the state already holds wage records, school data, and benefit history, would we begin by asking people to prove it all again? Probably not. We’d start with what we know and only ask for what’s missing.
Defaults Beat Intentions
Verification-first design isn’t a flaw; it’s a legitimate goal with real stakes. Public programs carry constraints most businesses don’t. Eligibility decisions need legal accuracy. Fraud prevention matters, and so does responsible use of public money. Data sits in separate agencies that don’t always talk to each other, and the work requirement itself is federal law, not something a designer can opt out of. Supporters argue the goal is encouraging employment and protecting program integrity, and I’ll leave that debate to others.
The usability question stands either way. Given the requirement, is the process built to help eligible people satisfy it, or does it make satisfying it harder than it needs to be? Verification and completion aren’t opposites; the goal is to build the checks so qualified people get through easily. The question isn’t which goal is legitimate; it’s whether anyone chose it on purpose.
Every product has its own version of this problem. Where do you make users prove something you already know? Where does one missed email or one wrong field end the relationship? What’s your default, and is it working for your users or against them?
If your success metric is “verified compliance,” you’ll build a verification-first system that optimizes for paperwork, and the people it loses along the way become a cost the design accepts. If it’s “eligible people who stay,” you’ll build something very different. The interface follows the metric, and the metric follows what you decided to care about; in product, that decision is usually made long before anyone opens a design file.