Designing a government service around the citizen, not the org chart

To design a government service around the citizen, start from the outcome the person is trying to reach, walk the whole journey to that outcome across every department and entity involved, and redesign the hand-offs between them, because that is where citizens wait, repeat themselves and give up. Then give one named person responsibility for the whole journey and measure it from the citizen's first step to their final result. Changing the screens without changing the hand-offs only gives the same journey a new look.

This is the government-specific companion to the hub's pillar, Customer-centric is a practice, not a slogan: where to start.

Why services end up shaped like the org chart

In 1968 the programmer Melvin Conway observed that organisations tend to design systems that mirror their own communication structures. Government services are a clear case. Each directorate builds the part it owns, to its own rules, with its own form. The citizen gets a journey that follows the structure behind it: one step per department, a new reference number at every desk, and the same question asked three times.

Nobody designs this on purpose. It happens because each department is measured on its own part. Licensing hits its processing target, inspections hit theirs, and the citizen still waits seven weeks, because the waiting happens between departments, where no one is measured.

Several governments now state this in their own standards. The UK Government Service Standard, for example, opens with "Understand users and their needs", then "Solve a whole problem for users" and "Provide a joined up experience across all channels". In Saudi Arabia, the Digital Government Authority, set up in 2021 by a Council of Ministers decision, sets the standards for government digital transformation. Check which standards apply to your entity before you start, and use them: they give your redesign an official mandate.

Step 1: Name the service the way the citizen would

Citizens don't use "the Commercial Licensing Directorate e-service". They are opening a café, or registering a newborn, or moving a parent into care. Name the service by that outcome and the scope changes right away: it now covers every step the person must take, including the ones your entity does not own.

Write one sentence: "A [person] needs to [reach an outcome] so that [what it makes possible]." If the sentence names a department, rewrite it.

Step 2: Walk the whole journey yourself

Before you map anything, live it. Run a service safari: apply for the service as a citizen would, using the public channels, with no internal shortcuts. Then watch real applicants with contextual observation, at the service centre, on the phone line, and if you can, at home while they fill in the form.

Speak to front-line staff too. Call-centre agents and counter staff know exactly where the journey breaks, because they hear about it every day. They are rarely asked.

Note three things at every step: what the citizen must bring, who they must deal with, and how long they wait with no news.

Step 3: Map the front stage and the back stage

Put the journey on one wall. Start with an experience map of what the citizen does, thinks and feels, step by step. Then add the layer underneath with a service blueprint, a method first described by G. Lynn Shostack in the 1980s: which department acts at each step, which systems they use and where the case passes from one team to another.

Mark every hand-off in red. In most government services the hand-offs explain the delays better than any single step does. If you are unsure which of the two maps you need first, see Journey map or service blueprint? When to use which.

Step 4: Find what the citizen is asked to carry

Look for the moments when the citizen acts as a courier between parts of government: getting a certificate from one entity to hand to another, re-entering data the state already holds, printing a form to scan it back in. Each one is a design choice the organisation made, usually without noticing.

List them. For each, ask: does government already hold this? Could the receiving department get it directly? What rule or system stops it? Some answers will need a policy change or a data-sharing agreement. Write those down as decisions for leadership instead of quietly dropping them.

Step 5: Give the whole journey one owner

This is the step most redesigns skip, and the reason many slide back. Each department keeps owning its part, but someone must own the journey: the end-to-end time, the hand-offs and the complaints that fall between teams.

Agree it in writing with a RACI for the journey: who is responsible for each stage, who is accountable for the outcome overall, who must be consulted on changes. The journey owner needs enough seniority to call a meeting across directorates and be heard. Without that, the new design is just a recommendation.

Step 6: Test the new journey before you change systems

Draw the redesigned journey and test it with real citizens and front-line staff before anyone writes a specification. A role-play at the counter, a paper version of the new form, or one officer handling a small batch of cases by hand under the new process will show you within days what a system build would show you after months. The sibling article Testing an experience before you build it covers these tests in detail.

Step 7: Measure the journey, not the department

Replace or add to the department-level measures with journey measures: time from first contact to final outcome, the share of applications that finish first time, repeat contacts per case, and the number of documents the citizen has to supply. Build them into a KPI tree so each department can see how its own measure feeds the journey. A satisfaction score alone won't tell you which moment to fix; Why everyone measures satisfaction and nobody fixes the moments that cause it explains why.

Worked example

Illustrative. A mid-sized municipality in Europe wants to cut complaints about permits for opening a small food business. Internally, the work belongs to four teams: business registration, planning, environmental health and signage.

The team names the service "Opening a café", walks it as an applicant and observes six real applicants. The blueprint shows eleven steps, three separate reference numbers and two points where the applicant must carry a document from one team to another. Most of the waiting sits between planning approval and the health inspection booking, which no one owns.

The redesign: one application, one reference number, the health inspection booked automatically when planning approves, and a named journey owner in the business registration team. They test it for a month by having one officer run twenty applications by hand through the new route before any system changes. The officer's log becomes the specification for the IT work.

Do's and don'ts

Do

• Name the service by the citizen's outcome, not by the department that delivers it.
• Include steps owned by other entities, even if you cannot change them yet.
• Bring front-line staff into the mapping. They hold the evidence.
• Record policy and data-sharing blockers as decisions for leadership.
• Appoint a journey owner with real authority across directorates.

Don't

• Start with the portal. A digital form on top of a fragmented process just moves the queue online.
• Map the journey from internal documents alone. Procedures describe how the service should run, not how it actually runs.
• Treat the redesign as finished at launch. Review the journey measures monthly for the first six months.
• Run the work inside one department and expect the others to adopt it.

Questions people ask

What does citizen-centred mean in government services? It means designing a service around the outcome the citizen is trying to reach and the whole journey to get there, across every department and entity involved, rather than around how the organisation is structured internally.

How do you redesign a government service that crosses several entities? Map the whole journey, including the steps you don't own, mark every hand-off between entities, and bring the owners of those hand-offs into one room to agree changes. Data-sharing and policy changes usually need a sponsor above all the entities involved. The Ecosystem innovation pillar covers how entities work on shared problems.

Do we need to digitise the service first? No. Fix the journey first, then digitise the fixed version. Digitising a fragmented process gives citizens the same number of steps, on a screen.

Where to go next

Start with a service safari this week, then map what you find with a service blueprint. When the new journey is clear, agree ownership with a RACI and set journey measures with a KPI tree. If you are setting up the team that will do this work, Starting innovation in a government entity: the first 90 days is the place to begin.