How To Easily And Consistently Map Life Event Journeys

In Business Process Management, Enterprise Architecture by IRM UKLeave a Comment

Print Friendly, PDF & Email

We look at life event journey mapping – what it is, and how we standardise the maps across different life events. At the DTA, we have been exploring life events in our efforts to understand a citizen’s experience interacting with multiple services delivered by several government agencies.

Graham Wilson, Business Architect, Robinson Ryan
Graham spoke at the IRM UK
Enterprise Architecture & Business Process Management Conference Europe 21-24 October 2019, London on the subject, ‘Emily’s Rebellion – Getting Cosy With Product Managers and Service Designers
The next Enterprise Architecture & Business Process Management Conference Europe will take place 26-29 October 2020, London
This article was previously published
here.

Taking a life events approach is a key process for enabling government that’s easy to deal with, which is a strategic priority of the Digital Transformation Strategy.

We quickly found that we needed a standardised way to map life event journeys so that all our life event maps have a similar structure and use a common language.

What are the components of a life event map?

Life event journey maps show the activities and tasks that people might perform when going through a life event.

Some of these activities and tasks are linked to interactions with specific government services, such as submitting a claim for Newstart Allowance.

Interactions that people have with non-government services are also important to understand, particularly when those services are funded by government. We also identify pain points that people commonly encounter.

Our structure for mapping life event journeys consists of a simple hierarchy which breaks down a journey into increasingly granular levels. A life event journey usually contains 4 or 5 big stages. A stage contains activities, an activity contains tasks, and a task contains 1 or more service interactions. As you go down the levels, the information gets more specific.

Life Event Journey: Users experience life events which require them to interact with government, for example having a baby.

Life Event Stage: Users experience these journeys in stages. Government may be involved in all or some stages, for example caring for a newborn baby.

Activity: A stage contains activities which are a collection of smaller tasks, for example complete administrative paperwork for my newborn.

Task: Tasks are small, individual actions that users perform to complete an activity, for example add baby to my Medicare card.

Service Interaction: Users may need to interact with government services to complete a task. A service interaction is expressed in government language, for example enrol newborn in Medicare.

Products and Services: Products are defined by government programs. Agencies design transactional and information services and business processes to deliver the product to users, for example how to enrol a newborn in Medicare [information service], enrol newborn. Typically, agencies focus on the user’s service journey for their product.

We express stages, activities and tasks in the language of users. On the other hand, a service interaction is expressed in government language so that there is no ambiguity about which service the user is interacting with.

For example, a user may describe their task as “apply for unemployment benefit” while the corresponding service interaction would be labelled “claim Newstart Allowance”. The more formal government language enables us to clearly link the task “apply for unemployment benefit” to the government product Newstart Allowance, delivered by Centrelink.

Life events vs. service interactions: Service interactions are the point where a life event journey intersects with the customer journey for an individual government product (for example, Carer Allowance). To distinguish them from life event journeys, we refer to these product-specific customer journeys as service journeys.

We incorporate information about government products into our life event maps, but we do not map service journeys. Service journey maps are ‘agency business’. That is, they are mapped – and improved where necessary – by the agency responsible for the product. A service journey map shows the customer’s experience when interacting with the set of information services and transactional services that the agency designs for its product.

Life event maps take a broader perspective and include many activities that an agency may not consider relevant to their particular service journey. However, these ‘irrelevant’ activities often have a profound impact on the citizen’s overall experience of the life event.

Pain points: Such negative impacts are called ‘pain points’. A pain point, such as having to provide the same information to government multiple times, is only apparent when we look at the whole life event journey. Since our focus is on improving people’s experience of government, we need an awareness of all the activities in the life event journey when designing a better experience for the future.

By understanding pain points, we can find new opportunities to make the experience better and prioritise improvements that directly address pain points. These improvements will help us to make government easy to deal with.

Graham Wilson is a senior Business Architect at Robinson Ryan, a specialist data management and business architecture consultancy in Australia. He has worked in government agencies for over 30 years, including as Chief Architect at Ministry of Agriculture and Forestry in New Zealand. Graham was a significant contributor to the operational business design of the National Disability Insurance Scheme in Australia. Specialising in business architecture, Graham works at the cross-roads where business meets IT. He has worked closely with Robinson Ryan director Lloyd Robinson to develop a generic structured pattern for specifying transactional services. He is currently developing life event journey maps in a government context, highlighting pain points that users experience when interacting with cross-government services.

Copyright Graham Wilson, Business Architect, Robinson Ryan

Leave a Comment