In the Lab+ experiment we have been testing the concept of what integrated services could look like into the future, including what a user's experience with government might be like. We have taken a strong user-centred approach to our service design. We intentionally created a safe, neutral place for people from different agencies to work collaboratively to explore what services could look like and what insights we could discover when you don't apply an agency-specific lens.
One of the outcomes of this work was, through the useful lens of a life event, to build some experimental future states for government service delivery, built entirely around the user's needs and taking into account the possibilities of multi-entity service delivery, while ignoring the limitations of the current landscape. Only by planning for what you want can you meaningfully change what you have, and iterating on the status quo can only take you so far.
We chose the events that occur around retirement and becoming a "senior" as our life event, as it traversed various agencies as well as the the private, NGO and public sectors. We analysed previous research as well as conducted our own (all to be published, appropriately anonymised), and were able to identify particular user needs and pain points along with some fascinating insights. This work helped us realise that people like to have different types of interactions with government to meet different needs, and at different points of the journey.
So, without further ado, below are the three concepts that clearly came out of the research we conducted.
Conversational services
When trying to actually interact with government, many users talk about wanting some assistance, both because it is complicated and they don't want to get it wrong, and also because having someone who understands your context can dramatically speed up the process. We found people didn't mind too much whether it is a person or a machine, but they really want visibility of the interactions that happen between agencies on their behalf, as that would give them the ability to correct the record (where required) without delays.
Users often record the names of people, the details and dates/times of discussions specifically to have a record for their own purposes. So the third element of this guidance/conversational future state was the idea that a transcript of all such interactions would be readily available to you, along with the option to interact in a timely way to keep processes that matter to you on track.
This future state starts with the assumption you've been notified about a change to something and that you have the opportunity to enter into a conversation about it. The concept could apply when you would engage with government for a number of services across agencies.
Video transcript
Pia Waugh [voiceover]: Welcome to Lab+ future states series: conversational services.
[Text on screen] Welcome to Lab+ future states: conversational services.In this example, a person has turned 65 since last logging on to their online banking. They get a new notification about not being eligible for NZ Superannuation and the user has a chance to explore the matter and get it resolved through a transparent multi agency conversation. The conversation could also be sparked through the person initiating the transaction. The person gets a notification via their online banking to let them know they are not eligible for superannuation.
The person is informed why they're not eligible for NZ Superannuation and choose to talk to their agent by clicking on a link. In this case, it's because they haven't been in New Zealand for 5 years. The chat session with an agent begins. The person explains their situation to the agent and asks for help. In this case they explain they have been in the country in the last 5 years.
[Onscreen] Shows a conversation in a chat window.
Agent: Hi John, how can I help?
[Voiceover] The agent asks if they're able to verify the information and the person agrees to upload a document demonstrating that they have been in the country using their passport.
John: I’ve been told I’m not eligible for Superannuation because I haven’t been in the country for 5 years since turning 50. But that is a mistake.
Agent: OK, sorry about that. Do you have any documents that show the real time you have been out of the country?
John: Yes, I can upload a notarised copy of the page in my passport.
The document is then uploaded and the agent has a chance to verify the document and make sure that is it appropriate, and to ask the user whether they're happy for the information to be verified with Immigration.
Agent: That would be great. Thanks for supplying that. I’ll need to loop immigration in to resolve this. If that is ok with you then click the button below to include them.
[Onscreen] John clicks the button to let an Immigration case worker join the conversation.
[Voiceover] Immigration joins the conversation, thus creating some transparency to the user about the information being shared.
Immigration Agent: Hi there. I’m Jan, Immigration case worker. We’ve amended you record to show you have been in the country 5 years and 2 months since 2002. Apologies for the inconvenience.
Agent: Your Superannuation will update in a few days to show you are eligible.
John: That’s great. Thank you.
The situation is then resolved and the agent is able to go ahead and fix the access to services that the person had original been told they were not eligible for.
[Video ends]
Proactive delivery
Secondly, there is a lot of interest within governments internationally to deliver services proactively. There is also a lot of mythology around just how far users want government to do this, and what is even possible. Our research found that users were quite keen for proactive service delivery, such as either being notified of being entitled to something or even automatically getting something from government.
Government data is necessarily retrospective however, so it can be dangerous and intrusive to try to predict, for instance, when people are moving country, or planning a child, or preparing for bereavement. We were aware of the danger of taking proactive delivery too far.
Our users talked to us about how something like being informed that their superannuation payments changing due to the death of a spouse was actually useful, but that some cultures would certainly find it confronting. User input led to the insight that proactive delivery should certainly be both developed in collaboration with users across cultures, and that people should be able to opt in to what they want proactive delivery for.
Video transcript
Pia Waugh [voiceover]: Welcome to Lab+ Future States: the proactive delivery.
[Onscreen] Shows a person logged into the Auckland Council website showing their rates bill details.
Pia Waugh [voiceover]: In this example a home owner gets an email from the council saying they may be eligible to a rates rebate.
In this notification they are asked if they asked if they are happy for the conditions to be confirmed with IRD as to whether they're eligible. They are asked if they will authorise the council to check their income with IRD to verify they earned under $50,000, the home owner says yes.
[Onscreen] Shows details on eligibility for a rates rebate and gives the person 2 options: “Yes, I authorise you to check my income with IRD”; and, “No, I do not authorise you to check my income with IRD”. The home owner selects “Yes”.
The home owner then gets their next rates rebate from council with the rates applied. This means that the application has been automated, with permission.
[Onscreen] Shows original rates bill minus a rates rebate amount.
[Video ends]
Help me plan
Thirdly, sometimes you just want some guidance or some information to help plan your life. We had some people say that they didn't want to ask a question in a way that identified them in case their lives were made harder by interacting with government. There are many times in your life when you just need to plan: to move, to consider having a child, to get married, etc. Sometimes people don‘t know all the services, requirements and implications of a life event, which can make them uneasy and also make planning difficult. For these types of interactions, we have a mode of delivery we call "Help me Plan". This prototype is being implemented as a working (but mocked up) service, specifically so we could dig below the surface to understand the functional requirements of such a solution.
The key here is that people want to be able to provide minimal information about themselves and their circumstances, in an anonymous/unauthenticated context, so they can get the services they need (including the ones they don't already know about). The potential future state mockup is purposefully generic, enabling a user's needs to be met through diverse options of functionality and mashing up of content, business rules and other functionality could be provided by government and non-government service providers; with government providing the baseline generic service and the private and community sectors specialising in particular user needs or market segments.
We are still working on this proof of concept and will have the user view of the concept ready to show within the week. Meanwhile, below is a walk through of where we are at right now. This future state proof of concept takes a little more work than the wireframes below due to having to reverse engineering the business logic of government services, but we think you will find it very interesting. So, some early thinking about codifying business rules can be found in this video.
Video transcript
[Background music plays throughout video: light guitar and bells.] The screen shows the title screen ‘Lab+ Future States — Help Me Plan — Exploring Potential Future Models for GOV Services’. Screen changes to reveal a page of code elements.]
G’day I' m Tinus [Wagner], software engineer from 3months [3months.com], and I'm here to give you a quick rundown on the progress we’ve made on the T65 application so far.
So, to start off, the first challenge that we had was the ability to map the business rules into a meaningful schema that’s machine-readable and relatively easy to add to.
So that’s what you can see here. We’ve grouped all our business rules under their perspective provider [The cursor highlights code identifying a provider, ‘Work and Income’]
And then the business rule we have here [the cursor highlights the business rule ‘Superannuation’, a service Work and Income provides.]
…and its associated requirements nested underneath [the cursor highlights the code identifying the 4 requirements for ‘Superannuation’, which are ‘Applicant Minimum Age’, ‘Years in NZ since [age] 20’, ‘Years in NZ since [age] 50’, and ‘Living in NZ?’.]
While this is an oversimplification of the problem [that] we’re facing, it does prove that there’s a way that we can input this and that it’s relatively easy to understand and relatively easy to build upon.
[The screen scrolls down to reveal more code defining 16 other business rules they’ve created for Work and Income services, namely: ‘Accommodation Supplement’, ‘Disability Allowance’, ‘Temporary Additional Support’, ‘Special Needs Grant’, ‘Super Gold Card’, ‘Funeral Grant’, ‘Community Services Card’, ‘Sole Parent Support’, ‘Emergency Benefit’, ‘School and Year Start-up Fund’, ‘Extraordinary Care Fund’, ‘Veterans Pension’, ‘Child Disability Allowance’, ‘Childcare Subsidy’, ‘Unsupported Child Benefit’, ‘Establishment Grant’.
So, for instance, in this current situation, we have about 40 business rules and we can apply it to them from about 6 different agencies as a little test case.
[The screen scrolls down to reveal more code for another provider, ‘Immigration Services’ that defines the business rule for the ‘Parent or Grandparent Visitor Visa’ service that has 8 requirements: ‘Proof of Identity?’, ‘In Good Health?’, ‘Of Good Character?’, ‘Intend to Meet Visa Conditions?’, ‘Sponsor is Child or Parent?’, ‘Sponsor is Resident or Citizen?’, ‘Sponsor is Relative?’, and ‘Cover own Healthcare Costs?’.]
So, what this does is, it enables our application to read and sort through business rules, even though in a very simplified method.
So, it allows us to group them by a life event. [Screen shows a mock up of the application page with the option to select from 4 life events, ‘Immigration’, ‘Retired’, ‘Health’ and ‘Childcare’.]
So, in our test application, we’re currently focusing on events related to immigration, retirement, health, and child care and it allows us to query this data and visualise them.
So, if I go to ‘Retired’ [the cursor selects ‘Retired’], I see a list of services that are available. [The cursor highlights 4 of the services that appear under ‘Retired’: Superannuation’, ‘Veterans Pension’, ‘Super Gold card’, ‘Funeral Grant’].
I can drill down into them and see any related dependencies for getting those requirements for accessing that service. [The cursor selects ‘Hearing Aid and Appliances Support’ to reveal 2 requirements: ‘Service-related Hearing Loss?’ and ‘Receiving Income Compensation Due to Hearing Loss?’. The cursor then selects ‘Veterans Independence Programme’ to reveal 3 requirements: ‘Being in Military Service’, ‘Require Support to Stay Independent’, and ‘Currently Living at Home?’.]
And I can also toggle multiple life events to return multiple services. [Cursor selects ‘Health’ and ‘Childcare’ as well, which reveals the services and the respective requirements that apply to these life events, too.]
So, this is at least a basic proof that this schema will be able to resolve, to deliver some sort of result.
The second portion of what this enables us to do, as you might have noticed, we have this first question here. [The screen shows the question ‘Minimum age of applicant’ with a choice between 2 answers that can be selected: ‘65 and over’ and ‘under 65’.]
So, being able to query all these business rules according to life event… [the cursor deselects the ‘Health’ and ‘Childcare’ life events and keeps the ‘Retired’ life event ticked.]
…also allows us to look at what's the most common question or requirement under these business rules. [The cursor hovers briefly over an extended list of services that appear below the ‘Retired’ life event.]
So, if I tick more than one, for instance, here [the cursor selects the ‘Health’ life event as well] you can see that the first question should look at the ‘minimum age’ of the applicant and it’s currently a core requirement in 4 of the business rules.
Or 8 [business rules] [the cursor selects the ‘Childcare’ life event as well].
Or 2 [business rules] [the cursor deselects the ‘Health and ‘Childcare’ life events, leaving just the ‘Retired’ life event].
And this is dynamic and easily queryable, and this what we’re starting to build up on now. So, the idea being that the user will toggle their life event [and] they will see the most important or the most common requirement as a question. Once they’ve answered this, we save that as a small part of their personal profile, locally, and then loop through to the second most common, the third most common, and start excluding or visualizing which benefits or business rules they have access to or may not have access to currently.
Thank you very much! [Return to title screen]
And have a look at this mindmap of entitlement rules.
This is a working proof of concept by 3months (a software services company that we’re working with to conceptualise some of the Lab+ work). You can experiment with to explore entitlements based on context, but please note it is a concept demonstration only, and not official nor to be assumed entirely accurate. Meanwhile, below is a walk through of where we are at right now. This future state proof of concept takes a little more work than the wireframes below due to having to reverse engineering the business logic of government services, but we think you will find it very interesting.
There are some examples of such "Help me plan" services already - like SmartStart (for services when expecting a baby) and NZReady (for moving to NZ). These services do help people get informed and take next steps, but the step beyond that for such an approach might be in:
- dynamic information and services based on user provided context;
- blending/integrating life events (our research showed a number of people in multiple life events which impacts their needs and planning); and
- supporting people to then progress with transactions where possible or desirable.
User considerations
There were two factors to clearly consider in taking this proactive approach to government service delivery.
- The complexity of the service - Customers clearly had a preference for low and medium-complexity services to be delivered automatically, however where the criteria for the service provision became more complex, or needed to take into account more of a user's context or nuance, automatic provisioning wasn't as preferred, due to customers doubting the accuracy of government data. Whilst we can expose that data to customers as per the scenarios we modelled, it might be worth highlighting that there was a somewhat inverse relationship between the complexity of the decision and the desire for automated provisioning.
- The nature of the decision - To a certain extent, the research reflected that customers were happy for automated provisioning to be in place primarily where it drives value for the customer, rather than where it drives value for government. For example, customers were less comfortable with the idea of automating the withdrawal of services or automation of decisions that could result in customers getting 'less' of something or being penalised for something. So as a rule of thumb, it seemed to be the case that customers said "Automating stuff is great if it means I get more of stuff, but when it comes to me getting less stuff or getting punished, I'd be less keen". Clearly we can't look to implement a 'two-sided' system that differentiates, however it provides a good indication of where messaging might need to be clear. So from a customer perspective, automation is great for service provisioning, rather than for compliance.
Conclusion
We started this experiment expecting to test a future state for government service delivery, and ended up discovering that multi-modal service delivery is useful to deal with the different ways people want to deal with government at different times, directly or through intermediaries. We are testing these ideas formally with users, but if you'd like to provide feedback as well, please either leave a comment below, or we will make a survey available in the coming days. We will be keeping this feedback separate from the formal user testing (due to the self-selective nature of people tuning in to this blog) but your feedback would be extremely valuable moving forward.
Finally, "Government as a platform" has been one of the foundations of our testing. Our work plan is available if you want to see our approach but in short, the approach makes components of government open so intermediaries or service providers can build new services, products and analysis on the shoulders of existing government components. The breadth of providers that are enabled using Government as a platform can better serve the requirements of an increasingly diverse community.
The more we do in this space, the more obvious that "mashable government" is the only sustainable and scalable approach to genuinely user centred services that don't simply serve the lowest common denominator, but rather facilitates the myriad needs and modes of people. Perhaps "gov as a platform" could be considered the "digital public infrastructure" of the 21st century.
Give us your thoughts
In the Lab+ experiment we have been testing the concept of what integrated services could look like into the future, including what a user's experience with government might look like.
Open Lab
Don't forget the Service Innovation Open Lab MeetUp every Friday from 4–5 pm at the Todd Building, 95 Customhouse Quay.
Lab+ is housed in the Service Innovation Lab, which is an experiment carried out under the leadership of the ICT Partnership Framework’s Service Innovation Group. It's managed by the Service Innovation Team in Department of Internal Affairs in partnership with Assurity Consulting.
Check out earlier blog posts about Lab+ and the Service Innovation Lab.
Follow us on Twitter at @NZLifeEvents.
Published
