Designing Better Public Services: What Large-Scale Government Teaches Us About Service Design

Government services affect some of the most important moments in people’s lives.

Applying for identification. Registering a business. Receiving healthcare. Paying taxes. Accessing financial assistance. Reporting an emergency. Securing permits.

Yet these experiences are often designed as separate forms, offices, websites, policies, and databases—even though citizens experience them as one continuous service.

A discussion hosted by the Service Design Network Dallas Chapter brings together Elisa Chen and Norah Maki from 18F and Victor Udoewa, then working in strategy at NASA, to explore what it takes to practice service design inside large government organizations. The conversation considers the complexity of public-sector stakeholders, the additional dimensions involved in government work, and the challenge of organizing service-design initiatives at scale. (YouTube)

The lessons are useful not only for government. They also apply to utilities, healthcare providers, universities, banks, large enterprises, and any organization whose services cross multiple departments and systems.

1. Context and Framing: A Service Is Bigger Than Its Interface

When an organization wants to improve a service, its first instinct is often to redesign the visible interface:

• Create a better website
• Simplify a form
• Build a mobile application
• Add a chatbot
• Modernize the visual design

These improvements may help, but they address only the part of the service that people can see.

A service also depends on employees, policies, approvals, databases, infrastructure, communications, partner organizations, and operational processes. Service design examines how all these elements work together to help someone accomplish a goal.

Imagine applying for a permit online.

The website might be attractive and easy to use. But the overall service still fails when:

• Applicants do not understand the requirements.
• Different offices request the same information.
• Records must be manually transferred between systems.
• Employees cannot see the status of an application.
• Approvals take weeks without explanation.
• Citizens must visit an office to correct a small mistake.

The website is only the front door. Service design examines the whole building behind it.

The diagram below shows why a public service should be understood as an ecosystem rather than as a single website, department, or transaction.

Official government design guidance describes service design as a process of understanding users, creating prototypes, testing services with the people who will use them, and making decisions from evidence rather than assumptions. (Government of Ontario)

2. Core Analysis: Why Large-Scale Government Services Are Difficult to Design

Government services operate as ecosystems

A public service rarely belongs to only one team.

It may involve:

• Citizens and businesses
• Frontline employees
• Department managers
• Policymakers
• Legal and compliance teams
• Technology providers
• Contractors
• Local and national agencies
• Advocacy and community groups

Each participant may have different responsibilities, incentives, limitations, and definitions of success.

This means the designer cannot study only the citizen-facing experience. The designer must understand the service ecosystem—the network of people, institutions, technologies, policies, and resources influencing the service.

Public services must work for diverse populations

A private company may choose a narrow customer segment. Government usually cannot.

Public services may need to accommodate people with:

• Different languages and literacy levels
• Disabilities
• Limited internet access
• Older or slower devices
• Limited technical confidence
• Difficult financial or personal circumstances
• Temporary physical or cognitive limitations

Accessibility is therefore not an optional enhancement added near the end of development. It must influence research, content, technology, facilities, staffing, and service delivery from the beginning.

18F’s accessibility guidance emphasizes that accessible design benefits not only people with permanent disabilities, but also people experiencing slow internet connections, changing abilities, caregiving responsibilities, illness, or temporary limitations. (18F Guides)

The visible problem may originate backstage

Suppose people complain that an application takes too long.

The immediate response might be to redesign the application form. But research may reveal that the real delay comes from:

• An outdated approval policy
• Manual data entry
• Incompatible databases
• Unclear employee responsibilities
• A missing document-verification process
• A procurement or staffing constraint

Service design prevents teams from treating the visible symptom while ignoring the system producing it.

Government service-design guidance distinguishes between the frontstage experience visible to the public and the backstage capabilities and processes required to deliver it. Improving one without the other rarely produces lasting change. (Deloitte)

3. Key Concepts Explained

Concept 1: The end-to-end journey

A user journey is not limited to what happens on a website.

It begins when a person recognizes a need and may continue through:

1. Discovering the service
2. Understanding eligibility
3. Preparing requirements
4. Applying
5. Waiting for a decision
6. Receiving updates
7. Correcting problems
8. Receiving the outcome
9. Renewing, appealing, or requesting support

A journey map shows this experience from the user’s perspective.

It can include:

• Actions
• Questions
• Touchpoints
• Emotions
• Pain points
• Waiting periods
• Information needs
• Moments of trust or uncertainty

An end-to-end journey map makes the full experience visible, including the moments where confidence rises, frustration grows, or trust breaks down.

 

Simple analogy: A journey map is like following a passenger through an airport. It shows what the passenger experiences from arrival to boarding—not merely what appears on the check-in screen.

Concept 2: The service blueprint

A service blueprint adds the organizational layers behind the journey.

Imagine the blueprint as several horizontal lanes:

User actions
What the citizen, customer, employee, or applicant does.

Frontstage interactions
What the person sees: websites, counters, emails, calls, staff conversations, receipts, and notifications.

Backstage activities
The invisible work performed by employees, reviewers, administrators, and partner organizations.

Supporting systems
Databases, policies, APIs, vendors, infrastructure, training, reporting, and governance.

Evidence and measures
Documents, confirmation messages, processing time, completion rates, errors, complaints, and outcomes.

Imagine these layers stacked underneath each stage of the user journey. Together, they reveal what the organization must coordinate to deliver the experience.

 

18F defines a service blueprint as a visual representation of the complete experience of using and supporting a service. Its purpose is to clarify the relationships among intertwined systems and processes and reveal opportunities for improvement. (18F Guides)

Concept 3: Stakeholder influence mapping

Not every stakeholder has equal authority or influence.

A frontline employee may understand the problem deeply but have little power to change policy. A senior official may have significant authority but limited exposure to everyday service problems.

Stakeholder influence mapping helps a team identify:

• Who is affected
• Who makes decisions
• Who controls resources
• Who possesses operational knowledge
• Who could support or block change
• Whose perspective is being overlooked

This is especially important in large institutions, where formal organizational charts do not always reveal the real distribution of influence.

Stakeholders should not all be managed in the same way. Mapping influence and interest helps teams decide who to engage closely, satisfy, inform, or monitor.

 

18F describes stakeholder influence mapping as a way to visualize stakeholders and uncover the often-unspoken power dynamics that may affect project outcomes. (18F Guides)

Concept 4: Human-centered research

Human-centered design replaces internal assumptions with evidence from real people.

Research may involve:

• Interviews
• Contextual observation
• Service walkthroughs
• Diary studies
• Analysis of complaints and support requests
• Interviews with frontline employees
• Accessibility research
• Usability testing
• Examination of operational data

The goal is not simply to ask users what feature they want. It is to understand:

• What they are trying to accomplish
• What makes the task difficult
• What workarounds they have created
• What information they lack
• What emotional or practical risks they face

Human-centered design is continuous rather than a one-time research activity. Services must be evaluated and adapted as people’s needs and operating conditions change. (Digital.gov)

Concept 5: Participatory design

In traditional design, experts study people and then design a solution for them.

Participatory design goes further by involving the people affected by the service in understanding the problem, generating ideas, evaluating alternatives, and shaping decisions.

This may include:

• Citizens
• Community representatives
• Frontline personnel
• Case workers
• Administrators
• People with disabilities
• Groups that have historically been excluded

The principle is simple:

People should not merely be sources of research data. They should have meaningful opportunities to influence the services affecting them.

Concept 6: Public value

A commercial service is often evaluated through revenue, conversion, retention, and profitability.

Those measures may not adequately describe the value of a public service.

Public-sector outcomes may include:

• Increased access
• Reduced processing time
• Fewer unnecessary visits
• Greater compliance
• Better health or safety outcomes
• Lower administrative burden
• More equitable access
• Increased public trust
• More effective use of public resources

The purpose of service design is therefore not merely to make a process feel more convenient. It is to improve the organization’s ability to fulfill its mission.

The following process should be understood as a learning cycle. Teams may move backward, revisit assumptions, and test several alternatives before implementing a service.

4. Step-by-Step Guidance: How to Redesign a Complex Service

Step 1: Define the service outcome

Avoid beginning with a proposed technology.

Instead of:

“We need a mobile application.”

Begin with:

“People need a reliable way to understand, submit, and track their application without unnecessary travel or uncertainty.”

This keeps the team focused on the outcome rather than prematurely committing to a solution.

Step 2: Identify users and stakeholders

List everyone who:

• Uses the service
• Delivers it
• Supports it
• Regulates it
• Funds it
• Makes decisions about it
• Is indirectly affected by it

Then map their influence, needs, relationships, and potential conflicts.

Step 3: Research the current experience

Observe the service as it actually operates—not merely as manuals and policies say it should operate.

Interview both users and employees. Look for:

• Repeated information
• Long waits
• Confusing instructions
• Manual transfers
• Unofficial workarounds
• Inaccessible touchpoints
• Missing ownership
• Points where people abandon the process

Step 4: Map the current journey

Visualize the complete user experience from initial need to final outcome.

Mark the moments where people experience:

• Confusion
• Effort
• Delay
• Anxiety
• Loss of trust
• Successful resolution

Step 5: Build the service blueprint

Place the backstage operations underneath each journey stage.

Ask:

• Which employee actions enable this step?
• Which policies affect it?
• Which systems exchange information?
• Where is human judgment required?
• Where could failure occur?
• Who owns the outcome?

Step 6: Identify root causes

Do not redesign every problem immediately.

Separate:

• Symptoms from causes
• Local issues from systemic issues
• Technology problems from policy problems
• Training gaps from process gaps
• Missing features from missing ownership

Step 7: Co-design possible improvements

Bring users, employees, managers, and technical teams together to explore alternatives.

Potential improvements may include:

• Clearer instructions
• Fewer requirements
• Shared data
• Better status notifications
• Revised employee workflows
• Alternative offline channels
• Policy changes
• New digital tools
• Better escalation processes

Step 8: Prototype the service

A service prototype does not need to be functioning software.

Teams can test:

• Paper forms
• Sample messages
• Role-playing exercises
• Clickable screens
• Simulated service counters
• Call-center scripts
• Revised workflows
• Manual versions of an automated process

The goal is to learn before making expensive commitments.

Step 9: Test with real users and employees

Test whether people can complete the service under realistic conditions.

Include participants who reflect the diversity of the actual population—not only confident digital users.

Step 10: Measure outcomes and continue improving

Government design guidance commonly organizes human-centered work into discovery, design, delivery, and measurement. The work continues after launch because a live service produces new evidence about user behavior and operational performance. (Digital.gov)

Useful measures may include:

• Completion rate
• Processing time
• Error rate
• Number of repeat visits
• Support requests
• Accessibility issues
• Employee workload
• User confidence
• Outcome achieved
• Differences between population groups

5. Practical Takeaways

The most important lesson from large-scale government service design is this:

A service cannot be improved by redesigning its interface alone.

Organizations must connect:

• Human needs
• Employee experience
• Operational processes
• Technology
• Policy
• Accessibility
• Governance
• Measurement

For business and technology leaders, this suggests five practical principles:

1. Start with the outcome, not the application.
2. Study the entire journey, not one touchpoint.
3. Include employees as service users too.
4. Treat accessibility and inclusion as core requirements.
5. Prototype changes before committing to large-scale implementation.

A beautiful interface placed on top of a broken process simply makes the broken process look better.

Service design goes deeper. It helps organizations understand why the experience fails—and redesign the system capable of delivering a better outcome.

6. Optional Deep Dive: From Service Design to Systems Change

Large public services often contain problems that no single department can solve.

Public value is multidimensional. A service may create value by improving outcomes, increasing access, reducing administrative burden, using resources responsibly, and strengthening trust.

 

For example, improving access to healthcare may involve transportation, employment conditions, digital connectivity, records management, funding, education, and community trust.

At this scale, service designers must combine service design with systems thinking.

Service design asks:

How can this service work better?

Systems thinking also asks:

What structures, relationships, incentives, and assumptions keep producing the current results?

This changes the role of the designer.

The designer is no longer only creating better touchpoints. The designer helps people across the system:

• Develop a shared understanding
• See dependencies and unintended consequences
• Coordinate decisions
• Test interventions
• Learn from outcomes
• Build the internal capability to continue improving

That is why service design matters in government—and why its lessons are valuable for every complex organization.

The goal is not simply to create better websites or smoother transactions.

The goal is to create systems that help people accomplish what matters.

This can be adapted into a shorter Facebook article or an eight-slide educational carousel.