Life-Event Service Design: Why Government Must Redesign Around Moments, Not Ministries

A woman in Amman loses her father. In the space of six weeks she must report the death to the civil registry, cancel his driving licence, close his bank accounts, transfer the family home, notify the pension authority, and update her own family book. Six agencies, six logins, six versions of the same certified copy of the same death certificate. Nobody at any of those counters asks how she is doing. Why would they? Their job is to process a transaction, not to witness a bereavement.

This is the default architecture of government: services built around departments, not around the events that actually happen to people. Life-event based service design flips that logic — it organises government around what is happening in a citizen's life (having a baby, losing a job, starting a business, grieving a parent) rather than around which ministry happens to own which form. It is one of the few structural ideas in public-sector service design that consistently reduces effort, cuts cost, and restores a measure of dignity to moments that were never supposed to feel like admin.

What is life-event based service design?

Life-event design groups every touchpoint a citizen needs for a given moment — birth, marriage, bereavement, unemployment, retirement, relocation — into a single journey, regardless of how many agencies sit behind it. Instead of a citizen learning the internal structure of government to get anything done, government absorbs that complexity itself and presents one coherent path.

The UK's Government Digital Service design principles, first published by GDS, put this plainly: design should start from user needs, not from government structure. "Tell Us Once" — the UK service that lets a bereaved family report a death a single time and have it flow to the tax office, pension service, and passport office simultaneously — is the clearest working example of the principle in practice. It exists precisely because the alternative is what our Amman example above describes: the same fact, told six times, to six strangers, in the middle of a family's worst month.

Why does government service design usually fail at life events?

Because government is organised by function, and life is not. A birth touches health, civil registration, tax, education and sometimes housing. A single ministry owns none of that journey — each owns a slice, measured against its own KPI, its own budget, its own IT system procured a decade apart from the next department's. Nobody in the org chart is accountable for the citizen's whole week.

The result is what Cass Sunstein calls administrative sludge — friction that serves no legitimate policy purpose and exists only because nobody owns the end-to-end experience. In his 2021 paper "Sludge and Ordeals," published in the Duke Law Journal, Sunstein argues that unnecessary friction in public administration is not a neutral inconvenience; it is a hidden tax that falls hardest on people with the least time, literacy, or emotional bandwidth to absorb it — precisely the people going through a life event. A grieving spouse or a newly unemployed parent has less capacity for forms than they did the week before. Government rarely designs for that.

Two behavioural mechanisms make this worse than it looks on paper:

• Cognitive load under duress. Decision-making capacity drops sharply under stress and grief — exactly the state most life events induce. A process that would be a minor irritation on an ordinary Tuesday becomes genuinely punishing during a bereavement or a redundancy.
• Loss aversion at the counter. Citizens fear losing an entitlement (a benefit, a pension, a subsidy) more than they value gaining one, so uncertainty about "have I done this right?" produces repeated, defensive check-ins — extra calls, extra visits, extra load on the very channels that are already strained.

Neither problem is solved by a nicer web form. Both are solved by removing steps, not decorating them.

What does life-event design look like in practice?

A handful of governments have built genuine life-event journeys rather than life-event landing pages — the distinction matters. A landing page with links to twelve different departmental sites is navigation dressed up as simplification. A real life-event service redesigns the back end so that one interaction triggers everything downstream.

Denmark's citizen portal, borger.dk, has organised major public services around life events such as having a child, moving house, or losing a spouse since the portal's redesign in the 2010s, pulling data from multiple registries so citizens are not asked to re-supply facts government already holds. Estonia's X-Road data-exchange layer underpins a similar principle: once a citizen reports one fact to one register, other public bodies can pull it rather than ask for it again — the "ask once" rule that has become a benchmark for digital government maturity across the EU.

These examples share a structural feature worth naming: the redesign happened at the data and process layer, not just the interface layer. A prettier front door onto the same six disconnected back-office systems is not life-event design. It is a life-event skin, and citizens learn to distrust it fast once the first form asks them to re-enter something they already gave.

How do you actually build a life-event journey?

The pattern that works in practice, whether the event is a birth, a bankruptcy, or a bereavement, follows a consistent sequence:

1. Map the journey from the citizen's first action, not the department's first form. Start the map at "my father died," not at "civil registry receives death notification." The starting point determines everything about scope.
2. Inventory every agency, document, and data point the event currently touches. Most governments discover, doing this properly for the first time, that the same three or four facts (identity, date, relationship, address) are asked for by every single department in the chain.
3. Identify the legally required "asks" versus the merely habitual ones. A striking share of repeated data requests exist because no one has revisited a form since the system that required it was retired.
4. Design one entry point that fans out data to every downstream system. This is a data-sharing and interoperability problem before it is a UX problem — the UK's Tell Us Once and Estonia's X-Road both solved the plumbing before they solved the screen.
5. Sequence the emotional arc, not just the transactional one. A bereavement journey should not open with a form; it should open with clarity on what needs to happen this week versus what can wait. Kahneman's peak-end rule applies here with unusual force: citizens will remember how the hardest step and the final confirmation felt, far more than the eleven administrative steps in between. Get those two moments right even if everything in the middle is merely competent.
6. Pilot with the agency that has the least to lose and the most to gain — usually the smallest, most citizen-facing department in the chain — before asking the largest, most risk-averse ministry to change how it works.
7. Instrument the journey end to end, not department by department. A citizen satisfaction score for the tax office's slice of a bereavement journey is nearly meaningless if the civil registry's slice is where the real pain sits.

That sequencing matters because most government transformation programmes do it backwards — they buy a new portal (step six, effectively) before agreeing what the journey even is (step one). The technology is rarely the constraint. The absence of a shared map is.

What breaks when governments try this?

Life-event design fails for predictable, structural reasons, and it is worth naming them plainly rather than pretending the approach is risk-free:

• No single accountable owner. A life event that spans five ministries needs one person or unit with the authority to make five ministries change their process. Most digital government units have influence, not authority — they can recommend, rarely mandate.
• Legacy systems that cannot share data. Interoperability is unglamorous and expensive, and it rarely has a ribbon-cutting moment, so it loses funding battles against visible, front-end projects.
• Legal and privacy constraints treated as immovable. Some data-sharing barriers are genuinely required by law; many others are inherited caution that nobody has tested against the current legal framework in a decade.
• Measuring the wrong thing. If each department still reports its own satisfaction score, there is no institutional incentive to fix the handoffs between departments — which is exactly where citizens experience the most friction.
• Treating the redesign as a one-off project rather than a standing capability. Life events do not stay solved. New benefits, new regulations, and new agencies get added to a journey continuously; without ongoing ownership, the fragmentation creeps back within a few years.

None of these are reasons to avoid the approach. They are reasons to start smaller and more honestly than most transformation roadmaps allow, and to fix the governance question before the technology question.

How should governments measure success at this?

Departmental metrics hide the very failures life-event design exists to fix. A government serious about this needs to measure the journey, not the transaction:

• End-to-end time to resolution — from the triggering event to the point every downstream obligation is closed, not from form submission to form acknowledgement.
• Number of times a citizen is asked to resupply information government already holds — arguably the single best proxy for how far "ask once" has actually been implemented, as opposed to promised.
• Drop-off and re-contact rates at each handoff between agencies — the moments where ownership changes hands are reliably where trust and time both leak out fastest.
• Citizen effort at the specific moments of truth, not an average CSAT across the whole interaction — a five-minute good experience followed by a two-hour bad one should never average out to "fine."

Building this measurement discipline is close to impossible without first knowing where an institution actually stands. A structured CX maturity assessment gives departments a shared, honest baseline before they attempt to redesign anything jointly — and it surfaces which of the failure modes above (ownership, systems, measurement) is the real blocker, rather than guessing.

Why does this matter more in the Gulf and wider MENA region right now?

Several governments across the region are mid-way through ambitious digital government programmes, and most have already solved the easier problem — putting individual services online. The harder problem, the one that actually determines whether citizens feel government is working for them, is the one this article describes: whether those services talk to each other at the moments that matter most.

A national ID system, a unified payments gateway, and a single sign-on are necessary infrastructure. They are not, on their own, a life-event journey. The test is simple and brutal: can a citizen report a death, a birth, or a relocation once, in one place, and have it flow to everything downstream — or does the shiny new portal still ask them to type their late father's date of birth into six separate boxes? Building genuinely joined-up experiences around these moments is exactly the work covered in our broader look at public-sector CX and digital transformation, and it is also, not coincidentally, where public trust is won or lost. Renascence has written previously about how institutional trust is built through experience, not through communication campaigns — life events are simply where that trust is tested hardest, because the stakes for the citizen are highest and their patience for friction is lowest.

Behavioural science offers one more useful frame here: choice architecture. Every default a government sets — which document is pre-filled, which channel is offered first, which step is optional versus automatic — quietly shapes how much effort a citizen has to spend. Designing life-event journeys is choice architecture applied at the scale of a nation, and it rewards the same discipline that behavioural economics brings to any complex decision environment: make the easy path the right path, and reserve friction for the places where friction genuinely protects the citizen.

Where should a government start?

Pick one life event — bereavement, birth, or unemployment are the three with the highest emotional stakes and the clearest cross-agency footprint — and map it properly with the sequence above before attempting a second. Trying to redesign every life event simultaneously is how these programmes stall: too many stakeholders, too many legacy systems, no visible win to build political will for the next one.

Mapping that single journey end to end, stage by stage, touchpoint by touchpoint, is the discipline behind our own CX journey mapping methodology, and it is also where service design earns its keep in government work — not as a branding exercise, but as the structural redrawing of who owns what, and when, across a citizen's worst or best week.

Government will always be organised into ministries; that is not the problem to solve. The problem worth solving is that citizens should never have to know, or care, which ministry does what. The measure of a mature digital government is not how many services it has put online — it is how few times it makes a grieving daughter say the same sentence to a different stranger.