Resident-Centered Service Design in Government
Governments must design services around residents' actual lives, not agency assumptions.

The terminology is not interchangeable, and the distinctions matter more than most people realize until they've watched a service fail the people it was built for.
Three terms circulate in this space: human-centered, citizen-centered, and resident-centered. "Citizen-centered" is the most common and the most problematic. It implicitly excludes non-citizen residents, the people who often rely most heavily on government services and who experience the sharpest friction when those services fail. The Lab @ DC's use of "resident-centered design" is an explicit correction: all local service users, regardless of legal status, are within scope. That is a deliberate equity choice embedded in nomenclature, not a semantic preference.
Human-centered design as a methodology draws on behavioral science, anthropology, and psychology. It has named stages, structured research methods, and a defined orientation toward evidence. The critical distinction from system-centric design is what it treats as the subject of inquiry. System-centric design asks how residents interact with a given form or portal. Human-centered design asks why residents behave as they do, accounting for the full context of their lives.
Georgetown's Donald Moynihan gives us a useful research lens here. He identifies three categories of administrative burden that residents absorb even when a service technically functions: learning costs, compliance costs, and psychological costs. A parent who qualifies for a benefit but never applies because the application language reads like a deposition has encountered a psychological cost. That cost is completely invisible to a designer who never left the agency's perspective. Entirely visible to one who started from the resident's.
I've sat in rooms where agency teams genuinely believed their service worked because their completion metrics looked fine. Nobody had talked to the people who walked away before completing anything. It's a bit like a restaurant giving itself five stars because the customers who stayed for dessert seemed happy — the ones who left after the appetizers aren't in your data.
Residents aren't comparing government services to what government used to offer. They're comparing them to what they used on their phones before opening a government browser tab. That comparison standard is permanent.
The policy environment that brought this methodology into formal government use
Resident-centered design in U.S. federal government has bipartisan roots, which is the single most important fact about its durability. The 21st Century Integrated Digital Experience Act passed under the first Trump administration and was enforced under Biden. Both administrations embedded customer experience in their respective President's Management Agendas. Executive Order 14058, Transforming Customer Experience and Service Delivery, placed human-centered design language directly into federal directives. Executive Order 13,985 required agencies to identify and redress inequities in programs serving underserved communities, connecting resident-centered design to a civil rights framing rather than a usability framing.
That linkage is significant. It means the methodology carries legal and moral weight, not just operational preference.
Internationally, the OECD's Global Trends in Government Innovation 2024 analyzed nearly 800 case studies from 83 countries and found a consistent thread: effective public service innovation centers people's needs and opens collaboration between service providers and users. The OECD also identified digital technologies not as optional enablers but as core infrastructure, naming a growing gap between rising citizen expectations and institutional systems that haven't kept pace.
What this policy environment creates, practically, is both mandate and permission. For government teams navigating internal resistance to change, that distinction is genuinely useful. You are not bringing a consultant's preference into a skeptical organization. You are bringing codified direction.
How discovery works when the starting point is residents' actual experience, not agency assumptions
Discovery is structured, time-bounded work. Per performance.gov guidance, teams conduct semi-structured conversations designed to surface personal stories, pain points, critical needs, and the moments that matter most in a resident's interaction with a service. These sprints typically run four to eight weeks. The time constraint is a feature; it forces prioritization and prevents the kind of open-ended research that never becomes a decision.
The Lab @ DC's approach starts by mapping the actual user journey: who the users are, then the specific barriers they face before they ever interact with a system. Those barriers include work hours that conflict with office schedules, childcare constraints, transportation costs, and financial burden. Only after that map exists does design begin.
Here's the kind of thing discovery finds: a renewal notice written in intimidating legal language is a failure point before the resident ever reaches a digital interface. A team starting from agency assumptions would never look for it, because from the agency's perspective, the notice was sent. Box checked.
Discovery asks "what is the resident's context?" rather than "how do we explain our process more clearly?" The target of inquiry is the person, not the service. That reorientation sounds small until you've watched it restructure an entire project.
Inclusion in discovery is not optional. Underrepresented residents experience different friction points, and they are typically more severe. A design process that excludes them produces a service that works for the median user and fails the people who needed it most. That failure is systematic. It compounds. And it is almost always invisible to the team that built the service, because those residents don't complain through official channels. They just disappear from the data.
For government teams working with constrained budgets, structured discovery sprints are an efficiency argument. They concentrate limited time and resources on solutions that will actually matter to actual people, rather than on assumptions that felt reasonable in a conference room.
What fragmented agency structures do to residents and how design addresses it
The fragmentation problem is well-documented and genuinely tedious to experience. State digital services are spread across dozens of agencies and systems. Residents applying for benefits, disaster relief, or a driver's license navigate multiple sites, create separate logins, and re-enter the same personal information repeatedly. This is not, at its root, a technology problem. It is an organizational logic problem that technology has inherited and, in many cases, amplified.
Residents do not experience the org chart. They experience government as a single entity, and they bear the cost of its internal divisions in the form of duplicated effort and inconsistent information. Asking a resident to navigate fragmented agency systems is like handing someone a map drawn by six different cartographers who never spoke to each other — every section is technically accurate and the whole thing is useless.
The "once-only" principle is the primary design response: information entered for one service is reused across others wherever possible. Bloom Works' approach for a state governor's office demonstrates a pragmatic implementation path. Rather than a single large platform replacement, which almost never works the way anyone hopes, the strategy is iterative. Agencies retain ownership of their services, and each incremental improvement builds toward a more connected experience.
Maryland's MD Think initiative takes a data-integration approach, breaking down silos to reduce how frequently residents must share personal information. That applies the privacy principle of data minimization alongside usability improvement. The two reinforce each other rather than compete, which surprises some people who assume privacy and convenience are inherently in tension.
What resident-centered redesigns have actually produced, in measurable terms
The Texas Benefits app has been downloaded more than one million times, with a monthly user base exceeding 900,000 Texans; 74% of document uploads happen via phone. Adoption at that scale signals that the design solved for how residents actually live. Not for how agencies imagined they would engage.
Deloitte's data from a state-level health and human services redesign shows digital adoption up 77%. Online portal accounts grew from 32,000 to 57,000. Email open rates reached 37% against a government average of 21%, and click-through rates hit 17% against a government average of 4%. These are behavioral numbers, not attitudinal ones. Residents didn't just report that the service felt better. They used it more, and they engaged with its communications.
NYC's 311 redesign and Michigan's benefits application simplification are cited as cases where human-centered design produced measurable improvements in delivery and set new expectations for government-resident interaction.
The ACSI Federal Government Study 2025 recorded a score of 70.4, a 19-year high and the fourth consecutive year of improvement. That trajectory confirms that sustained investment in experience design produces cumulative gains, not a one-time uplift.
The honest caveat: individual redesign outcomes vary. What the evidence supports is that the methodology consistently improves on whatever it replaces. It does not guarantee uniform results. But the direction of travel is consistent, and that consistency is the argument.
Estonia's proactive service model as the furthest-developed expression of resident-centered design
By December 2024, Estonia had made nearly every government service available online. That is a 30-year build, not an overnight transformation, and anyone who dismisses the model because Estonia is small and relatively homogeneous is missing the more transferable point.
On EU Digital Decade metrics in 2024, Estonia scored 98.9 for digital public services for businesses and 95.8 for citizens. A 2024 OECD survey found that 82% of Estonians expressed satisfaction with public services, with 72% preferring digital channels. Satisfaction and preference are aligned. In most countries, they are still in tension.
The X-Road data exchange system handled over 2.7 billion data queries in 2024. That is the technical backbone that makes the once-only principle work at national scale, and it enables something most governments cannot yet imagine: initiating services before residents have to ask. The government acts; the resident receives.
The birth-benefits process is the clearest illustration. As of 2023, 99.99% of births are automatically checked for eligibility. The process takes 30 seconds. Service satisfaction sits at 91%, and there has been an 88% reduction in the need for parents to contact government workers at all. Estonia didn't just improve its forms — it eliminated the need to fill them out in the first place.
Ukraine's Diia app, with 19 million users and more than 100 services as of 2024, demonstrates that this logic is not confined to small, wealthy nations.
What is replicable is the design logic: start from the life events residents actually experience, not from the categories agencies have organized themselves around. That part doesn't require 30 years.
Why resident-centered design has to be a continuous process rather than a project with an end date
Human-centered design is explicitly defined as a continuous process. Resident needs evolve. Expectations, shaped by private-sector products that themselves keep improving, evolve faster. A service that works well today is one missed iteration cycle away from falling behind.
The government context compounds this in a way private-sector teams rarely have to reckon with. Administrations change. Policy priorities shift. Budgets fluctuate. A service that functions well at the end of one administration faces institutional pressure to drift back toward agency convenience when the people who built it move on. The drift is predictable, and it needs to be designed against, not hoped away.
The discovery-design-delivery-measurement cycle is meant to loop, not terminate. The measurement stage feeds back into the next discovery sprint. Bloom Works' iterative model only holds if agencies actually return to the cycle. The discipline here is organizational, not merely methodological. You can have the best process in the world and still lose it to a budget cut or a reorganization if it hasn't been embedded in how the organization operates.
Feedback mechanisms have to be built into service architecture from the start, because residents rarely complain through official channels. They abandon the service. They tell a friend it doesn't work. They show up at a field office instead. The data has to come to the team, because the team cannot wait for residents to find their way to it.
The ACSI trajectory, a net gain of 9.9% over four consecutive years through 2024, tracks with sustained, multi-administration commitment. Not a single redesign event. Not a platform launch.
The practical implication for government teams: budget and staff for iteration as part of the service's operating cost. Not as a separate improvement initiative. Not as a grant-funded project with a sunset date. As the ongoing cost of delivering a service that continues to serve the people it was built for.


