The Median User Doesn't Exist: Designing Public Services for the Digital Divide

Optimizing a public service for the average user quietly filters out the unbanked, non-native speakers, people without a smartphone, and citizens with disabilities — precisely who most public programs exist to reach. Equity isn't a layer added on top of usability. In government, it is the success metric, because the mandate is universal access, not average satisfaction.

Quick Answer: Designing for the median citizen excludes the people public services are legally and morally obligated to reach. Build personas from documented exclusion (unbanked, limited English, no smartphone, disability), stress-test the edges before the happy path, and measure success by completion rate for the hardest-to-reach segments — not by an average that hides them.

Why Designing for the Median User Quietly Excludes the People Who Need Public Services Most

Commercial teams optimize for the median user because the median converts — it's the cheapest path to the most revenue per dollar of design effort. That calculus inverts in government: the citizens furthest from the median (lowest income, least reliable connectivity, weakest institutional trust) are often exactly who a program exists to reach, so excluding them isn't statistical noise. It's mission failure.

A benefits portal built around a stable broadband connection, a checking account, and comfortable English literacy will test beautifully in a usability lab staffed with people who resemble the team that built it. It will also fail silently for the applicants who most need the benefit, because they rarely register in an analytics dashboard as a bounce. They register as an application that was never started.

The scale of this gap is not hypothetical. Roughly one in four adults in lower-income US households rely on a smartphone as their only home internet connection, according to Pew Research Center's ongoing surveys on technology adoption — meaning any flow that assumes a laptop, a large screen, and stable Wi-Fi taxes exactly the population most likely to need a public benefit. A few patterns show up repeatedly once you look for them:

• Device assumptions: forms sized for desktop, requiring multi-tab uploads or split-screen reference documents
• Bandwidth assumptions: image-heavy pages, auto-playing video explainers, uncompressed PDF downloads
• Time assumptions: a 45-minute session in one sitting, when hourly workers and caregivers rarely get one
• Trust assumptions: forms that read like a bank's terms of service, in a system many applicants already distrust

For a fuller map of how government product work departs from commercial SaaS assumptions at almost every stage, see our govtech complete guide. The short version: in commercial software, the median user is the business case. In public service, the median user is usually already fine.

Personas Built from Exclusion, Not Convenience

Traditional personas are built from your most engaged or most profitable users — the people whose needs are already easiest to serve. Equity-centered personas invert that. They start from a documented reason a citizen fails to complete a public-service flow, then design the primary path around clearing that barrier first, rather than treating it as an accommodation bolted on afterward.

Four exclusion categories recur across almost every citizen-facing service, and they compound rather than arrive one at a time:

The FDIC's National Survey of Unbanked and Underbanked Households has repeatedly found unbanked rates in the low single digits nationally, rising into double digits for Black households, Hispanic households, and households that include a person with a disability. A "verify via linked bank account" step isn't a minor edge case — it's a structural exclusion aimed disproportionately at the populations many benefit programs specifically target.

The job a citizen is hiring the service to do — get rent assistance, renew a license, prove eligibility for a subsidy — doesn't change based on which channel or device they happen to have. Our jobs-to-be-done complete guide covers how JTBD reframes need independent of interface, which is useful here precisely because it stops a team from treating "no smartphone" as a different job rather than a different constraint on the same job.

For disability specifically, this isn't optional generosity in the US federal and most state contexts — it's baseline law. Our guide to the Section 508 accessibility legal baseline covers what compliant actually requires beyond a checkbox audit.

These categories rarely show up in isolation. A citizen can be simultaneously unbanked, a non-native English speaker, and reliant on a shared, older smartphone with a prepaid data plan. Treat each persona as a stackable constraint, not a mutually exclusive segment — a stress-case scenario later in this article depends on that assumption holding.

The Emotion Curve: Where a Benefits Application Loses People at Identity Verification

Plotting a citizen's emotional state across a benefits application — from initial hope through confusion, anxiety, and either relief or abandonment — reliably shows the steepest drop at identity verification, not at eligibility screening where teams usually expect it. Identity-proofing tools built around stable addresses, credit history, and smartphone possession treat anyone lacking those as a fraud risk by default, adding friction at the exact moment trust is most fragile.

A typical curve looks like this, stage by stage:

1. Awareness (cautious hope) — a citizen hears a benefit exists and might apply to them.
2. Starting the application (motivated) — a plain landing page and short intro form feel achievable.
3. Eligibility screening (mild anxiety) — disclosing income and household details feels invasive but survivable.
4. Identity verification (steep drop) — a knowledge-based quiz pulled from credit history, a smartphone selfie match, or a bank-linked check locks out anyone without a credit file, a smartphone camera, or a bank account.
5. Document upload (fatigue) — no scanner, an unreliable phone camera, and a data cap turn a five-minute task into three failed attempts.
6. Submission and confirmation (relief) — only for the applicants who survive steps four and five.

NIST's own Digital Identity Guidelines (SP 800-63) acknowledge that knowledge-based verification and phone-possession checks systematically underperform for people with thin credit files, shared devices, or no fixed address — directionally consistent with the pattern many public-benefits teams report: identity-proofing steps see far higher abandonment than any other single step in the flow. The failure isn't a UX polish problem. It's a verification method chosen for a citizen who isn't the one applying.

A one-time passcode texted to a phone number sounds like a reasonable fallback, until the phone is shared with three other household members, the SMS gateway drops it under a weak rural signal, or the plan ran out of texts before the deadline. Each "safer" fallback tends to encode the same identity assumptions as the primary method, just one layer down.

This is exactly the shape an emotion-curve mapping exercise exists to expose — plotting friction and sentiment against each step rather than judging the flow only on aggregate completion rate. Our customer journey complete guide walks through the underlying method in more depth.

A Plain-Language Rewrite Framework for High-Stakes Government Text

A plain-language rewrite isn't a copyedit pass. It's a five-step framework: audit the current reading level, strip legal and bureaucratic phrasing down to plain verbs, front-load the required action before the explanation, chunk instructions under scannable subheads, and test the rewrite with people who actually struggled with the original — not with colleagues who already understand the program.

1. Audit. Run existing text through a readability formula (Flesch-Kincaid or similar) and compare it against your actual applicant population's reading level, not your team's.
2. Rewrite. Replace "individuals in receipt of remuneration exceeding the threshold specified in Section 4(b)" with "if you earn more than $X a month." Cut nominalizations ("submission of documentation") back to verbs ("submit your documents").
3. Front-load the action. Lead every paragraph with what the citizen must do, then explain why — the reverse of how most regulatory text is drafted.
4. Chunk under subheads. One idea per short section, so a citizen can find "what counts as income" without reading four paragraphs of eligibility law first.
5. Test with real strugglers. Recruit from people who abandoned, called a help line, or asked a caseworker for help with the original version — they surface failure modes a fluent reader never will.

The Plain Writing Act of 2010 established plain-language requirements for US federal agency communications, and the Center for Plain Language has since documented that most government forms still test several grade levels above the reading proficiency of the population they serve. Nielsen Norman Group's usability research has long put average adult reading comprehension in the US at roughly a 7th-to-8th-grade level — a benchmark most eligibility text blows past without anyone intending to exclude a single applicant.

Before: "Applicants must furnish documentation substantiating household income for the preceding twelve-month period prior to adjudication of eligibility." After: "Show us what your household earned in the last 12 months. We'll use this to check if you qualify."

Stress-Testing the Edges Before Launch, Not After a Complaint

Happy-path testing validates that a form works for someone who has everything the form assumes. Stress-case testing validates the form for someone who has none of it. Before launch, run scenario tests that stack multiple barriers at once — a non-native English speaker without a smartphone, an unbanked applicant with a cognitive disability — because in the real world these barriers compound rather than arrive one at a time.

Many of these constraints are locked in during vendor selection and requirements-writing, long before an interface is drawn. Reviewing how sourcing decisions shape what's even buildable is worth doing early — our guide to designing product around government procurement covers that sequencing. Just as often, the real bottleneck is a decades-old identity-verification system inherited from a legacy contract, not the new front end layered on top of it; our public-sector legacy modernization strategy guide covers how to sequence replacing those systems without breaking service continuity mid-migration.

Making Equity the Success Metric, Not a Compliance Afterthought

A public service that reports 92% satisfaction among people who completed it has measured nothing about equity if the population who never completed it isn't in the denominator. The real success metric is completion rate by exclusion-risk segment — unbanked, limited English, no smartphone, disability — tracked separately, never blended into an average that hides exactly the gap the program exists to close.

This changes how prioritization frameworks like RICE or Kano should actually get scored inside a public-sector roadmap. A fix that raises completion for the 5% of applicants without a bank account should often outrank a polish item that nudges satisfaction for the 80% who were already going to finish — even though the aggregate impact number looks smaller on a spreadsheet. Reach and impact have to be measured against the segment that's actually excluded, not the whole population blended together.

Mapping this in practice means being able to see, step by step, where trust, comprehension, or access breaks down rather than only where the aggregate funnel narrows. Prodinja's Customer Journey emotion curve is designed to let a team plot exactly these moments in a public-service flow — the same identity-verification cliff described above — so it becomes a visible planning input reviewed before launch, rather than a pattern reconstructed later from support tickets and abandoned-application reports.

Key Takeaways

• The median user is a commercial optimization target, not a government one — in public service, the citizens furthest from the median are often the exact population the program exists to reach.
• Build personas from documented exclusion (unbanked, limited English, no smartphone, disability), not from your most engaged or easiest-to-research users.
• Identity verification, not eligibility screening, is typically the steepest drop point on a benefits-application emotion curve, because most identity-proofing methods assume credit history, a smartphone, and a bank account.
• A plain-language rewrite is a five-step framework — audit, rewrite, front-load, chunk, test with real strugglers — not a copyedit pass.
• Stress-test flows by stacking barriers, since exclusion factors compound in the real world rather than showing up one at a time.
• Track completion rate by exclusion-risk segment, not blended satisfaction averages, so equity gaps stay visible instead of getting diluted into a headline number.
• Many exclusion points are locked in at procurement and legacy-system decisions, well before an interface is ever designed.