Life-Event Service Design: Fixing Government's Wrong Unit

A woman in Cairo loses her father. In the same week, she must notify the pension authority, cancel his health insurance, transfer the car registration, close his bank mandate, and update the family record at the civil registry — five separate queues, five separate forms, five separate copies of the same death certificate. Grief becomes an administrative project. This is not a technology failure. It is an architecture failure: government built around ministries, not around the moment a citizen is actually living through.

Life-event based service design fixes the wrong unit of analysis. Instead of organising services around departments (transport, health, tax, civil status), it organises them around the events that actually happen to people — having a baby, losing a job, moving house, retiring, bereavement — and builds a single journey that pulls the right agencies in behind the scenes. The citizen tells their story once. The government does the coordinating, not the citizen.

What is life-event based service design?

Life-event service design is the practice of structuring public services around the real-world situations that trigger a need for government — birth, marriage, job loss, disability, death, starting a business — rather than around the internal org chart that happens to hold the data. A birth touches the civil registry, the health ministry, tax authority, and often housing or social support. A citizen doesn't experience those as four institutions; they experience it as one event: we had a baby. The design task is to make the service match that mental model.

The United Kingdom's GOV.UK platform was one of the first large-scale examples: its content architecture is explicitly organised by life events and situations rather than by department, a founding principle of the UK's Government Digital Service when GOV.UK launched in 2012. Denmark's citizen portal, borger.dk, does the same, grouping services under "life situations" such as having a child, becoming ill, or getting divorced. Neither hides the machinery of government — they simply refuse to make the citizen navigate it.

Why do government services still organise around departments, not citizens?

Because budgets, mandates, and accountability lines are drawn by department, and service design tends to follow the money. Each ministry owns its own data, its own case management system, its own legal basis for collecting information, and — critically — its own KPIs. A ministry is measured on processing its own forms correctly, not on whether the citizen's overall life event went smoothly. Nobody in the org chart owns "the death of a parent" as an outcome; a dozen people own fragments of it.

This is what the public-administration scholars Pamela Herd and Donald Moynihan call administrative burden — the learning, compliance, and psychological costs a citizen absorbs to access a service they are entitled to. In their 2018 book Administrative Burden: Policy by Other Means (Russell Sage Foundation), Herd and Moynihan argue that burden is rarely accidental: it is the residue of designing services around institutional convenience rather than citizen capacity. Every duplicated form, every "please visit in person" requirement, every "we don't have access to that system" moment is burden manufactured by department-first design.

Richard Thaler gave the behavioral-economics term for this in a short 2018 piece for Science titled "Nudge, not sludge" (Thaler, 2018, Science, vol. 361, issue 6401). Sludge is friction that serves no one — the frictionless nudge's evil twin. Asking a bereaved citizen to queue at five counters with five certified copies of the same certificate is textbook sludge: it protects no fraud risk that a shared data check couldn't catch, and it taxes the citizen precisely when they have the least capacity to pay that tax.

What does life-event design actually look like in practice?

The clearest examples share one mechanic: the citizen submits information once, and the state redistributes it internally, instead of asking the citizen to be the courier between agencies.

• Tell Us Once, United Kingdom — a service, coordinated through GOV.UK, that lets a citizen report a death a single time and have that notification automatically routed to the relevant departments — HM Revenue & Customs, the Department for Work and Pensions, the passport office, the driving licence agency, and local council services — instead of contacting each one separately.
• SmartStart, New Zealand — a single online journey at smartstart.services.govt.nz that lets new parents register a birth, apply for a tax number, and apply for the government's Best Start payment through one connected flow spanning Births, Deaths and Marriages, Inland Revenue, and the Ministry of Social Development.
• Life situations, Denmark — borger.dk structures its entire portal around situations such as illness, unemployment, and family change, so the entry point is the citizen's language, not agency nomenclature.

What these have in common is invisible to the citizen and hard-won behind the scenes: interoperable registries, agreed data-sharing rules, and a shared definition of "who owns this life event end-to-end" even when no single ministry legally owns the whole thing.

What's the behavioral-economics case for redesigning around life events?

Three mechanisms explain why this approach outperforms department-first design, beyond the obvious efficiency argument.

Cognitive load at the worst possible moment. Life events that trigger government contact are disproportionately high-stress: bereavement, job loss, illness, divorce. Behavioral science's dual-process model — System 1 (fast, intuitive) versus System 2 (slow, deliberate) — tells us that under stress, System 2 capacity collapses first. Asking a grieving or frightened citizen to hold five agency logins, five reference numbers, and five sets of opening hours in their head is asking for System 2 effort exactly when the least is available. Life-event design absorbs that complexity into the back end, where officials — operating in a calmer, System 2 state — are far better placed to manage it.

The peak-end rule and public trust. Daniel Kahneman's peak-end rule holds that people judge an experience overwhelmingly by its most intense moment and its ending, not its average. A citizen's peak moments with the state cluster around life events by definition — that's precisely when the interaction matters most and is remembered longest. A smooth Tell Us Once experience during bereavement builds more institutional trust in a single afternoon than years of adequate, forgettable transactions. A badly designed one does the reverse damage, and it does it during the highest-stakes encounter that citizen will have with the state that year.

Loss aversion and the entitlement gap. Administrative burden doesn't just cost time — it causes people to abandon benefits they're legally entitled to, simply because claiming them feels effortful and uncertain. This is loss aversion working against the citizen: the immediate, certain cost of navigating a confusing multi-agency process outweighs, in the moment, an uncertain and delayed benefit. Life-event design collapses that cost, which is why take-up rates — not just satisfaction scores — are the real test of whether the redesign worked.

How do you actually build a life-event service journey?

This is not primarily a technology project, even though it eventually needs technology. It is a governance and journey-design project first. A practical build sequence looks like this:

1. Name the event, not the transaction. Stop scoping "renew a driving licence" and start scoping "I've turned 70 and need to keep driving legally" or "my spouse has died." The event, not the individual form, is the unit of design.
2. Map the full journey across every agency the citizen touches, including the parts that currently sit outside any single ministry's dashboard — the phone call to the bank, the trip to the notary, the wait for a paper certificate. A cross-government service blueprint, not a single-department process map, is the right artefact here.
3. Identify the moments of truth — the two or three touchpoints in the journey where the citizen's trust is won or lost, usually the first contact after the triggering event and the point where they discover whether they need to repeat information they've already given.
4. Agree data ownership and sharing rules before building anything digital. This is the step most transformation programmes skip, and the one that kills most of them eighteen months in. Legal basis for sharing a death notification between the tax authority and the pension fund has to be settled by policy and law, not assumed by a project team.
5. Build a single entry point with an orchestration layer behind it — one form, one login, one tracked case — that routes to the agencies that need to act, rather than a directory of links to twelve separate portals.
6. Pilot with the highest-burden event first. Bereavement and birth are usually the strongest pilots: high emotional stakes, well-defined data needs, and near-universal population reach, which makes the case for further investment easy to build.
7. Measure completion and abandonment, not just satisfaction. A citizen who gives up halfway through a life-event journey and never contacts the state again looks like "no complaints received" in a badly designed dashboard. Track drop-off by step, not just end-of-journey CSAT.

What breaks when governments try this — and how do you plan around it?

Most life-event programmes stall for reasons that have nothing to do with citizen research and everything to do with institutional incentives.

• Legacy systems that can't talk to each other. Thirty-year-old case management platforms built for a single ministry's mandate rarely expose clean APIs. Orchestration layers have to be built as a translation layer over legacy, not as a replacement for it — replacement timelines run into years the citizen doesn't have.
• No single accountable owner. A life event that spans five ministries needs a governance body with real authority to force data-sharing agreements and joint KPIs, not a coordinating committee with no teeth. Without this, "whole-of-government" initiatives quietly re-fragment along the old departmental lines within a budget cycle.
• Privacy and consent design done badly. Citizens are rightly wary of "tell us once" if it looks like "we'll now share everything about you forever." The best implementations are explicit and narrow: this specific notification, routed to these specific agencies, for this specific purpose, with an audit trail the citizen can see.
• Funding tied to departmental outputs. If a ministry's budget is approved against its own processing volumes, it has little incentive to redesign a journey that hands part of "its" transaction to another agency. Life-event funding usually needs a dedicated cross-government budget line, ring-fenced from departmental allocations.

How do you know it's actually working?

Satisfaction surveys are a lagging and easily gamed signal in government CX. Three measures tell you more, faster:

Contacts per life event. Count how many separate interactions — forms, calls, in-person visits — a given event currently requires, then track that number down over successive design iterations. This is the single cleanest proxy for burden reduction, and it's far harder to game than a satisfaction score.

Take-up rate among eligible citizens. If a benefit or service tied to a life event is legally available to everyone who qualifies but only a fraction claim it, that gap is a design signal, not a communications problem to solve with more posters.

Time-to-resolution from the citizen's first contact to the last agency closing its file. Departments will happily report their own processing time as "fast." What matters is the citizen's total elapsed time across the whole event, which is usually two to three times longer than any single agency's internal metric suggests. Assessing where an institution sits on this kind of cross-government maturity curve is exactly what a structured CX maturity assessment is built to surface, benchmarked against the building blocks that separate a form-processing government from a citizen-centric one.

Where this leaves public-sector leaders

The instinct to digitise a form is not the same instinct required to redesign a life event, and confusing the two is why so many "digital government" programmes deliver faster versions of the same fragmented experience. A PDF turned into a web form is still five interactions if the underlying journey is still five interactions. The redesign has to happen at the level of the event, across institutional lines that no single minister fully controls — which is precisely why it needs deliberate governance, not just good intentions and a UX team.

Governments that get this right stop measuring themselves by how many services they've digitised and start measuring themselves by how few times a citizen has to explain their own life to the state. That is a harder metric to hit, and a far more honest one. It is also, increasingly, the metric citizens use to judge whether their government deserves their trust at all.

Renascence works with public institutions across the region on exactly this kind of cross-agency journey redesign — from mapping the full citizen experience of a life event to building the governance that keeps departments accountable to a shared outcome. Explore our public-sector CX and digital transformation practice, or see how structured CX journey mapping and a clear CX governance strategy turn a life-event ambition into a funded, owned, measurable programme. For a related read, our piece on linking CX initiatives to outcome metrics covers how to make the business — or in this case, the public — case stick beyond a single budget cycle.