Transcript of Pia Waugh's presentation
OK. I'm guessing that Sean's been waylaid, so I'll have to skip, unfortunately, Wellington. I will quickly say that the reason that I invited Wellington to present is because Wellington City Council have done just some of the most amazing work that I've actually seen in the world in terms of smart city stuff. Most cities around the world, they say, OK, let's do some smart city stuff. Let's put some, I don't know, GPSs on the buses and actually get some real time data of buses moving about.
Wellington sort of said well, there's actually a whole range of stuff that we don't know yet what all be opportunities are. So let's not put GPSs on buses. Let's actually build an entire sensor network. So here are some things you may not know about the city that I just found out. There is real time sensor backbone network in the Wellington CBD. They capture real time information about number of people walking along, about things like bird calls, and then they do automated counting of the number of birds and the populations and the different species and movements, which also then translates to rodents and pests.
So rather than people counting them every day, they're actually being understood. They are looking at things like, obviously looking at weather and all those kinds of information as well. But they're doing real time use of that data to inform policy from what used to be entirely manual processes. Some very, very clever things. And those sensors are very multi-purpose sensors, are all around the city. And very, very interesting to look at.
So I'll get some of that information to share a little bit later. But there's some very good stuff there. And a lot of their innovation is happening because they effectively funded a private sector largely, lab, which is one of the places that Mark lives. And basically said, you can use this space. We'll come and play, and clever things that come out of it we want to figure out how we can use, which is a very good business model and something interesting for us to have a look at.
So what I wanted to quickly talk about was Gov as a Platform. There's a couple of things I'm going to quickly talk about before we break into the more interactive part of the workshop, and less presentations and more talking. A few of you know a bit of what we've done. I might just grab that whiteboard, quickly. Let's just talk about a couple of good things.
Everyone can sort of see that OK? I'll move it forward a bit. So what we're going to do, I want to talk about two things specifically. The first one will be, Gov as a Platform. And then it will be, why Gov as a Platform. And that will make it a bit more real. So the first thing I want to quickly look at is, some of you have seen this before, but bear with me for those that haven't. Who hasn't seen this model of Gov as a Platform?
You guys haven't been. No? OK, so I'm just going to quickly give the context first, which is kind of important. And it wraps together some of the things that we've seen. So what we saw, overseas, is that user centered designed and Agile as methods, are being applied in a lot of government design and service delivery around the world. And what that's lead to is a new service, which might be more focused on the user.
That all sounds really good in principle. Unfortunately, what often happens is that the actual route of implementing that service, from that government agency, is the same old back end which is entirely siloed, entirely bespoken, entirely subject to that particular purpose. So the problem is that we saw in the UK, we saw in Australia, and I think also in the US a bit too, a lot of much better services for users needs today, but built in a way that couldn't actually be iterated to user's needs tomorrow. And that were built in a way that were subject only to solve that particular problem, and not actually to enable other problems we don't know. So it was kind of like targeted innovation if you like, but not serendipitous innovation.
So the experiment, and what we did over the first couple of months, just to break it down and fit it into this context, was how can we actually add to that a way of building in a modular, reconsumable, mashable way, so that we can actually enable a more diverse population of solutions to actually serve the needs of the community, the needs of society, the needs of our customers, if you want to use that word, in government? And also, how do we take advantage of — there are myriad service intermediaries out there, in the private sector, community sector, on councils, in museums. There are myriad service intermediaries or providers out there that are doing things, that if we can actually make it easier for them to re-use and leverage what government does, fundamentally, then that would actually create an opportunity to get some real innovation around that service delivery.
So what we experimented with was the idea of Gov as a Platform. Not government as a single platform, or an API gateway, or any of those things. But government as the platform that the community can build upon. So what we started playing around with was, well, every service has some form data or content, some form of information. Some of that stuff is specific to that particular service. And some of it is fairly generic. A list of services is fairly generic. The specific information about this service and why you want to use and how you use it is fairly specific.
But what's generic, make generically available. Make it available as an API. Come back to the APIs in a second. We also find a lot of services have transaction services, have something which is actually an interaction with government, that's actually applying to something, or reporting something, or receiving something — an actual transaction. And again, trying to make those API enabled.
And then the business rules is a big one as well. We had a few agencies say, all we want to do is, once we know something about a person, we want to give them what they need. It's like, yeah, but to do that, you need to compare what they are like the context about the person which by the way doesn't rely on them logging on. It can actually be a context you can get from behaviour or context they provide, or context that is relational. There's a whole bunch of ways you can do this. But it also requires information about the things and the business rules about those things, so you can actually do that as matchmaking.
So why wouldn't you build those for your clients in a way that could be reused in myriad ways? Making all those things available as many APIs on a, if you like, a high trust through to completely open framework, where as much as possible is made open, because high trust means that you end up having a re-use case might be your agency, or it might be a highly trusted service intermediary, which might be government or non-government. But every time we have a relationship with someone in government, the paperwork usually drowns innovation.
So what you want to do is only have targeted partners where you have to have targeted partners, and make as much as you can openly available for people to innovate. So then what you get is the ability for government to do its service delivery better, because its actually mashing up its own things and actually reusing its own things. So rather than us building APIs for other people to build upon that we don't actually use ourselves, which inevitably leads to bad API design. I know of at least one API here which is, as we've discussed and discovered, triple encrypted, which makes no sense. And if you were consuming it yourself you just wouldn't build it that way.
So consuming your own APIs is a critical part of this. So if we consume our own APIs, first of all, our front end, as we discovered MyMSD, as we discovered with SmartStart, an empty front-end that draws all of its really relevant stuff from a back end, now you can suddenly iterate your front-end. You can solve the user needs today, tomorrow, and into the future. This can change channels. It can change purpose. And as we've seen with examples even here in New Zealand and a few internationally, but some really good examples here in New Zealand, they can suddenly actually pivot the front end, pivot the user experience to better serve the user needs and better serve the goals of government as well.
But if you don't build them this way, you can't pivot quickly if you're suddenly having to change the front end or your SAP environment, or something else similarly large and difficult to work with from a changing perspective. The second opportunity it means is that other agencies can suddenly mash up across different things. We can actually have reusable components here. And the other, of course, huge opportunity here is all those service intermediaries out in the public domain who are naturally motivated to build on the back of government, who already build on the back of government but they do it by scraping, they do it by all kinds of tricky, annoying, frustrating, and resource intense methods that actually doesn't — it's actually taking away from their ability to do high quality service delivery.
So if we can make it so that the Citizen Advice Bureaus of the world, and many others, can actually consume information about our services, about our entitlement rules, about my laptop having a serious problem. If we can actually make it so that they can all actually draw on what government is authoritatively doing, all the logical rules, or artifacts government, then — and this is where it gets clever — if the problem space is only going like this, in terms of over time, and in terms of, so that's time and that's the complexity of the problem space. If government only usually does this, often does this, sometimes does this. The only way for us to actually respond to this problem space in this way is to actually enable others to respond as well, not just to try to be everything to everyone. It doesn't work.
At the same time, it doesn't mean we shouldn't be anything to anyone. We can't go the other way and be nothing to anyone. We need to be both an enabler and a provider, because government provision of services also creates that baseline that then the marketplace has to go above and beyond, rather than the marketplace doing what the market will allow, which often actually is where market segmentation drops off. The high complex, high vulnerable, high costly services, which we actually have to deliver.
So, Gov as a Platform is about enabling opportunities for agencies across government and beyond government to build value. And of course, all of this needs to be built on evidence. So a big part of our work is actually looking at service analytics, working across and working collaboratively with the other strategies across government, obviously, and working closely with our colleagues around the data space. But service analytics will then help us both inform this work, understand this work, and also provide cute little things like personalisation engines so you can say here's some other things that are related.
Anyway, getting away from the work agenda briefly, the quick things we wanted to demo. We wanted to test Gov as a Platform as a concept. And to do so, we built some demonstrators. Before we built the demonstrators, we went and looked at user research. We went and looked at what was done. But then ignored what was done to actually do completely independent user research about one of the life events, just as a test case, because it's a useful lens to go across agencies and across domains.
And it was fascinating, because some of our insights were new to the lead agency for that particular life event. Some of the insights wouldn't — when you say to people, would you like to, which one of these two rocks do you want? You don't have the opportunity to identify a spoon. And I've seen so much research, particularly in Australia, where it's more about product research — let's figure out how to make this product better. But what if the best solution for the customer is that there's no product?
What if the best solution for the government is also that there's no product? The problem is that product management without purpose can too quickly lead to, I guess, a Lord of the Flies approaches to how to make my product survive, regardless of whether it actually suits the purpose or not. So I'll just very quickly show the three modes of delivery that came out of our research. And the reason this is important is because it shapes what could happen up here, and it helps us understand by reverse engineering these modes of delivery, what the customer's experience with government could look like.
But gives us all the opportunity to identify and prioritise what could be built down here to actually support this work up here.
So the three modes of delivery that came out of our research just briefly. The first one was proactive delivery. Proactive delivery — I won't play the sound because it's my terrible accent voice. The first one was the idea of, rather than everyone having to constantly apply, why wouldn't certain things, and only certain things, not everything, be able to be proactively supplied to you?
We tested the idea of people automatically getting free transport for some of our elderly, and that just being notified to you that you now have free transport. Use your card. It will just work. We tested the concept of people being told, you're likely eligible. Are you happy for us, on your behalf, to actually verify your eligibility with, in this case, it's a means test for rates rebates with IRD.
And it was interesting. We tried to be a little intentionally creepy, because we wanted to see if there was a line that people didn't want us to cross. Even the example we did, which was, we've noticed that your spouse has died. That may have an impact on your NZ Super, people actually really liked that. So we need to obviously go a little harder with that.
But it was a really interesting demonstrator, because in seeing this, you've been notified about something. Yes, I'm happy to go through our ID to check it. And now I get my rate rebates automatically applied. We did about five different examples, scenarios, for each of these concepts, but proactive delivery as a concept, we tested in myriad different ways.
The second concept was the idea that people don't like to always log in. They don't always need to actually transact with government. They want to be enabled and supported to actually help themselves, effectively. So if you can imagine a person moving to New Zealand who is maybe 55, 60, because they are a grandparent, to be the primary carer so that they're kid can go back to work, was one of our scenarios. This isn't a user interface. This is a logic engine, so just bear with the ugliness of it.
I don't think it's ugly because I'm not a front end person. But the idea would be that you might provide some context, answer some questions. And again, we would to do a bit more work around making this logic engine a bit more seamless. But as you start to go through things, you start to say, OK, well, let's see what I'm eligible for or not. And the idea here is that, if people don't mind not being eligible for things, but they want to know why.
In this case, it's because they haven't completed a needs assessment. OK, now I know. I can go and talk to government and start from an informed perspective. Now what's interesting is, these are just conceptual tests, and conceptual ideas. In this particular one, you've also got the uPort that Matt mentioned before, where you can say you know what? The context you need to know about me, to inform this service, I'm actually going to use my personally controlled, encrypted profile which happens to live on blockchain in this particular example.
But most people, of course, would never use that language or think about it in that way. But the concept of a personally controlled profile that can be shared with government is an interesting concept that again, we tested with people and the results were very interesting.
And the third one was conversational. This one is based on the idea that since the person has last logged into their bank, they've turned 65. The bank was the number one service intermediary that retirees actually talk to about retirement, which again was a very interesting insight that we found.
I apologize for the Star Wars beginning. So the person logs into their bank and they're told, sorry, you're not eligible for NZ Super, but happy birthday. The person says, why is that? That sounds ridiculous. And they're told, oh, because you haven't been in the country for more than five years since turning 50.
And they say, well, actually that's not true. So I want to engage into a conversation with the agent. Interestingly, people didn't care if the agent was a bot or a person, so long as they could choose the gender — fascinating. We are a strange species. Anyway, so the idea here is that you go through and you actually have a conversation.
Here's the situation. Here's what our records show. Do you mind if I bring Immigration into this conversation? Yes, bring Immigration into the conversation. Immigration come in and actually confirm that yes, you have been here. Record gets fixed and the whole problem gets resolved.
Three key concepts out of this. Engaging, so conversational, that real time conversation to actually resolve the matter. The second thing is drawing in the actual actors, rather than me engaging with you, and then you go engaging with them and coming back and then coming back to me and being like, what's going on that months have passed by now and I haven't got what I need? And the third one, of course, is that permanent record. People love the idea of having a persistent record of their exchange with government.
So I won't show any more of that right now. There's a lot of work we did in that first experimental phase of Gov as a Platform. We then reverse engineered as a first test case to see, what would make sense to build down here? We've now got several life events kicking off with agencies where they're trying to look at building the services and we're looking at, OK, what reusable bits can we make to actually make that easier, make it persistent and make it consistent? And how can we actually take this pure user centred design that isn't user centred through the lens of an agency perspective design?
So there's some interesting work happening there too. I'll close up here and I think I'll move back to Amelia to hand over. Thank you very much.