How to easily and consistently map life event journeys
We look at life event 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.
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.
Users experience life events which require them to interact with government, for example having a baby.
Users experience these journeys in stages. Government may be involved in all or some stages, for example caring for a newborn baby.
A stage contains activities which are a collection of smaller tasks, for example complete administrative paperwork for my newborn.
Tasks are small, individual actions that users perform to complete an activity, for example add baby to my Medicare card.
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 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 [transactional service]. 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 “submit Newstart Allowance claim”.
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.
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.
Why is this important?
Using the life event structure to map life events enables the govX team to analyse and discuss life events more easily because we are all speaking the same language.
It also allows us to look across life events and find issues and opportunities that are common to more than one life event.
We encourage agencies to adopt our life event structure in their own work. Taking a life events approach helps to identify improvements that are centred around helping people, regardless of the level of government or organisational boundaries.
The govX life event communities assist us to build the collaboration required for this approach. This collaboration is being facilitated through the Australian Digital Council.
Graham Wilson is a Business Architect in the govX team.