GDS Podcast #33: Digital identity - working with government services

We discuss lessons learned when it comes to digital identity, the importance of cross-government collaboration, and how other service teams can get involved.

The transcript for the episode follows:

-------------

 

Vanessa Schneider:

Hello and welcome to the Government Digital Service Podcast. My name is Vanessa Schneider and I am Senior Channels and Community Manager at GDS.

 

Today, we will expand on our plans to remove unnecessary complexity by developing one inclusive and accessible way for people to log in to all government services online. An easy way to prove their identity just once, that also gives them control over who has access to their data and why.

 

I'm joined by Will Myddelton, Product Manager, and Helena Trippe, Senior Service Designer, both in the Digital Identity programme here at GDS, as well as Tom Stewart, Assistant Head of Modernisation at Veterans UK, that have been working with GDS to test their technology and processes. So let's start with you Will, would you mind introducing yourself to our listeners?

 

Will Myddelton:

Of course, Vanessa. Hi everyone. I'm Will, I'm a Product Manager on our Identity workstream. And what that means is on Digital Identity, we've split the work into 3 streams. We have one for authentication, we have one for identity, and we have one for managing data. And my work is to lead the work on our 3 teams that are thinking about the identity part of that puzzle. And as a Product Manager, really, my role is to set the direction that we're going in. And the way that we really do that is by building a shared understanding between all of the different teams so that we all understand the problem that we're working on, with the goal that we can work as the wonderful autonomous human individuals that we are. 

 

Vanessa Schneider:

Fantastic, thank you Will. Helena, how about you, would you please introduce yourself?

 

Helena Trippe: 

So my name is Helena. I'm a Service Designer in Will's team and in the Digital Identity stream. I have been in the programme since, for-for a year now. And it's really, really fantastic to see the excitement growing both within the programme and also across service teams for the work that we're doing. And it's growing in momentum all the time.

 

And my role within the team has really been to act as a little bit of a glue. We're a multidisciplinary team: we have User Researchers, we have Interaction Designers, we've got Business Analysts and trying to make sure that we are feeding in a lot of the learning back into the product development as we iterate and learn from service teams.

 

Vanessa Schneider:

Great. Thank you, Helena. Finally, Tom, would you like to introduce yourself as well, please?

 

Tom Stewart:

I'm Tom Stewart. I work for Veterans UK, a pillar of Defence Business Services, part of the Ministry of Defence. I'm the service owner for a service called the Armed Forces Compensation and War Pension Scheme. Essentially the, the service is: if you are, if you are a service person or you were a service person and you have an injury or a condition that you believe is attributable to your time in the service, then you may be entitled to some form of compensation. And we're, we're digitising what was previously a bit of a paper heavy service. I run, I-I lead a little multidisciplinary team. And my role was the, the kind of overall responsibility for the development and the, the operation and the, the continuous improvement of the scheme.

 

Vanessa Schneider:

Fantastic. Thank you, Tom, for introducing yourself as well. So there are people who might not be following GDS's work within the digital identity space, it's hard to believe, Will and Helena, but can you tell me about what your team has been working on?

 

Will Myddelton:

Anyone that's been working in government over the last 10 years knows that GDS has worked on a product called Verify for a long time, and Verify came from a really good place. It is a real common need of service teams to be able to check the identity of their users. We knew that right after we made GOV.UK right back at the start of GDS and Verify was started to address that need.

 

The pandemic was a, a really big event for digital identity in the UK. Verify usage shot up. But at the same time it magnified all the problems that there were. And so in last year's spending review, the government committed money back to GDS, which given some of the reputation we've got for doing digital identity in the past, but we're really honoured to, to be trusted to do this, to tackle digital identity from the centre of government once again.

 

And so what we've been doing since really 1 April - like that's when our, our funding settlement came in and we've got a year of funding - is we've really been trying to work out what the right approach to tackle digital identity this second time around is.

 

And we've had to be really open with ourselves and with the people that we speak to. And believe me, people around government are open with us about what we've got wrong with Verify. But we've also had to be open to the fact that there were some things that we got right in Verify that we're going to continue. So since 1 April, we've done a discovery period on identity and we did twin discoveries, one into the needs of end users and one into the needs of service teams.

 

And then from June until where we are now, we've been in an Alpha. And so what we're doing in our Alpha is experimenting with different ways that we can do digital identity better at GDS for the whole of government; and particularly how we can, this time round, design a digital identity product based on the needs of service teams.

 

Because my observation from having worked on Verify in 2015 and then having worked on, like, the next generation of platform products that we made in GDS - like I was involved in the Notify Alpha and Beta and I worked on Pay and I worked on all those Government as a Platform Products - is that by the time we started those, we'd changed our stance on how we thought about developing products for the whole of government.

 

By the time we came to 2015 and did all those Government as a Platform products, we had to instead develop things that were so good that services wanted to use them. And we developed a number of ways of thinking about product development for platforms that are going to be used by service teams across government in that 3 years, 2015 to 2018.

 

And so really why I'm here and what we're trying to do in our Alpha is, we're trying to apply those techniques to a very, very complicated and slightly overwhelmingly complex space of digital identity. We're trying to design a product that solves digital identity for the UK users of government services in a way that service teams will adopt because they love it.

 

Helena Trippe:

And if I can add a little bit of the how, I guess, in terms of how we've been delivering that: we started very early on, even in Discovery stage as, as we've moved into the Alpha, kind of honed that a little bit more, to work very collaboratively with service teams, engaging them early on and trying to really put things in front of them so we get their feedback quite quickly and working iteratively to, to make sure that we can test their expectations. We can understand kind of how they understand identity, what are their mental models around it, that we can also start testing how we are communicating these things to really get feedback really quickly and iteratively and kind of engage them throughout the process. So that's, that's kind of something that we started through the discovery and are continuing to do that through the Alpha. And I believe we'll continue to do and, and grow as we, as we move on.

 

Will Myddelton: 

We're, we are trying to make it easier to access government services where every user has a single set of credentials, typically username and password, that they can use to access any government service in the future so that users don't have to remember lots of different passwords, but also so that like new and exciting things can happen with the future of digital services, where we can start to think about sharing data more easily between services.

 

And so a key part of that: digital identity is no longer a standalone thing for us. Digital Identity is really a feature of your login to government or your GOV.UK account.

 

So at the point at which a service like Universal Credit knows that, it needs to know that you are who you say you are to pay you our money, the idea is that you will be logged in with your account, you will do an identity check that will allow Universal Credit to pay out money to you. But then that identity check result will be saved so that every other service that you use after Universal Credit doesn't have to go through the same process. So there's a huge user benefit there, which means you don't have to do this very difficult process again and again.

 

And there's actually a huge government benefit there, which is that we can start to design services that expect you to be who you say they are, which, which opens up all sorts of interesting possibilities.

 

Vanessa Schneider: 

Thank you so much for sharing with us, yeah, what, what you are working on. I was wondering, why is this work important for government service teams?

 

Will Myddelton:

That's a really good question. So...like with all the platforms that GDS makes for government service teams, we've got 2 sets of users and the really obvious one is the end users. And it's really important that we get the identity journeys right for them. But the less obvious one and the one that it's always taken us a while to work out how to design for are service teams around government. So we've done maybe 50 different interviews and research sessions so far with service teams about identity over the last 6 weeks.

 

And I think there's, there's kind of a few big reasons: one is that it makes identity checks easier for their users. Checking people's identity documents is often quite an onerous process in government. You might have to go down to the Post Office and hand stuff over. You might have to go to have an interview with a passport examiner. You might have to send your passport away - like there's lots of examples where passports are sitting in envelopes in government like processing centres, and that means the user doesn't have that passport for a long time. So services care a lot about their users. And so making things easier for the users when it comes to these difficult things like proving your identity, that's a really big benefit to the service teams.

 

A second thing that has come out of the research is that, services care a lot about including all their users. So one of the things when we talk about identity that service teams are very worried about is that, yeah, there can be a digital journey that might work for people that have like high strength identity documents, like passports and driving licences and are able to do things digitally online - and that's fine for those users.

 

But services are very worried about people that don't fit into that group, and that's a lot of people. And so they're worried about that for a couple of reasons. One: because the people that run services are generally really good people and they care. Like they just care, and they want to include everyone that should be able to use their service. And if we're running an identity check and that's the thing that excludes them, then that's a real problem.

 

But the other reason that service teams care a lot about this is: cost. And it costs service teams an awful lot to, any time someone can't do something in a kind of automated routine way, and that service team has to do manual processing or they have to procure a contract with a supplier so that the people can go and do things with them. So there is actually like a quite a hardcore cost saving element as well, which is that the less inclusive our platform is or identity checks are, the greater the burden of cost, time and effort the service teams have to bear.

 

Really, what guides all our work at GDS about platforms for service teams is that: we think that service teams should be able to spend their budgets and their time and their human creativity solving the problems that are unique to their service and identity is not really a unique problem. So really behind all of our work is this goal to save service teams time and money by not focussing on problems that everyone has, and instead to be able to focus on their unique users and the service that they're doing.

 

Helena Trippe: 

I think in terms of the findings that we've been seeing through the research, is that service teams really want to be able to do the right thing. So as part of the, the product page concept testing, we started to see that as they kind of engage with information, particularly around like choosing the right level of strength or understanding what documents can be used, they're constantly kind of making those calculations in their head around kind of what's the right trade off, for the sets of users that I'm, I-I need to kind of make sure that I get through my service.

 

But also, I think another aspect, that for me was really interesting was that we, we also need to kind of be, be aware that we're trying to kind of give them the tools and the information also to make a case internally; to be able to help them convince, I guess, external and internal stakeholders and decision makers about why this is a good thing to, to, to use in the dot. And that, that was really, really, really mind-blowing, at least for me [laughs], in terms of making sure that we can get them to see themselves in, in, in the tools and the information that we're providing.

 

Vanessa Schneider:

That’s great to know. Obviously we have a service owner present which is priceless, so if you don’t mind me asking, Tom, what are your thoughts on this?

 

Tom Stewart:

Yeah, I thought perhaps I could add a bit of colour to some of the things that Will and Helena are saying. So when you consider our users, you know, a great deal of our users are, are veterans right? And I say the word veteran, and, and I'm going to guess that many people listening today, your, your mind immediately went to a 90-year old Chelsea pensioner with a red coat.

 

But of course a, a veteran can be 17 years old, a veteran can be someone who's had one day’s service, accidentally shot themselves in the foot and, and are, are out of the service. And that person is still, is still you know very much a veteran. But that person is a, you know, a lot more digitally literate than the, probably than t-t-the Chelsea pensioner.

 

I suppose what I'm saying is the, going back to Will's point, i-it was about inclusivity. You know, that's very much at the front of our minds as we, as we develop this service. Cost, yes, i-it, but, of course it factors in. Making it easier for our teams, yes, absolutely vital.

 

But the, the, the last thing that I don't think I've heard mentioned yet is also, it's about, it's about plugging into the kind of strategic landscape. So my, my ability to, to verify users, has, has a much wider applicability for our business. So, yes, it's great I can use it for Armed Forces Compensation, War Pension - fantastic. But there's so much more that I can do with that. And actually, once we have done all of the work with the integration et cetera, we can quickly pivot at that point to right, ok, we've cracked this. We're answering a whole question. Now what can we do for these people over here? 

 

Helena Trippe: 

What we started to see as well is particularly from speaking to local authorities - so we have been speaking to a few local authorities as part of the, the, the research process, that almost identity is an enabler for them to do all sorts of things, including getting staff onto the systems to be able to allocate work or do casework or, or process council tax information. 

 

Vanessa Schneider:

That is brilliant to hear. So I know that within 4 months, you've talked to more than, I don't know, it's been hundreds and hundreds of end users, multiple dozens of service teams. I'm really keen to find out what it is that you've learnt so far?

 

Will Myddelton: 

Yeah, I mean, there are new learnings too. So talking about the approach we've taken, I think it's important to talk about that, that we take 2 different approaches when we're thinking about designing the service team.

 

So, so the one that we talk about mostly here is, is a very bottom-up approach. It's recognising that services are delivered by small groups of motivated people working in a really distributed government, where actually sometimes the lines of communication and control from the top of the department are not always clear. So sometimes sitting at the centre of government, it looks like you can make a change around government by speaking to the departments and that that will filter down. But our experience with Government as a Platform is that's, that's absolutely the opposite of what's going on here. 

 

So we have a 2-pronged approach to how we think about designing with service teams. One is that we, we, we want to speak to people who are working in service teams, any people - Product Managers, Technical Architects, caseworkers, policy people - because these are teams of people and they, they vary considerably around government, so we want to speak to people who are thinking about identity.

 

And the reason we want to speak to them is: we need to be able to do a user-centred design process with those people that might include, like interviewing them about their context and their needs or showing them prototypes of what we're doing and seeing how they land with them and how we're talking about it or like actually watching them integrate with our system. So when we're, got some documentation, sitting them in with Developers and watching them go through our onboarding steps. And all of that is in service of: we're trying to shape the product to meet their needs and then we're trying to communicate about the product in a way that makes it clear that we meet their needs and then we're trying to make the product easy to use so that there are no barriers to them using it.

 

Unfortunately, in government, like there is no like recruitment agency that goes out and finds us service teams and there is no list of service teams in government. So what we really have to do, and we learnt this on Notify and Pay and Government as a Platform, is we have to generate hype about what we're doing and then have people come to us. And that's a really good test for us, because what it says to us is: if what you're doing is not exciting, you're not going to generate demand, which doesn't give you people for research, which means you can't generate a product that meets user needs. So it's a really high bar for us to go through. But that's the bar that, that makes this stuff work for us; is we have to generate excitement and then turn that excitement into research sessions with people that haven't seen our product before and then use that to develop a product that really excites people. It's like a little virtuous circle.

 

So we spent a bunch of time setting up that process and part of why we're on this podcast and talking about it so that anyone that hears this that works on a service team or knows people that work on a service team is thinking about identity, we would love you to get in touch and take part in our research. It's fun. Like we are really, you know respectful people, we're here to understand your stories. And you will get to play with the early versions of our prototypes and our product and you will get to influence direction. So that's the bottom-up approach.

 

But we also are not naive. We understand that there is a top-down approach as well. So we are out engaging with all of the major departments that provide identity solutions. In the last couple of weeks, I've been in really quite amazing sessions with HMRC [Her Majesty's Revenue & Customs], DWP [Department for Work & Pensions], Home Office - these people that have been grappling with identity for years, and they're very graciously sharing their learnings and their challenges and things that they should tell us to watch out for.

 

But Vanessa, what you really asked is what we've learnt, so one of the things that we've learnt is that we, we do have to be able to talk about how we're different to Verify, because people that think about digital identity know about Verify. And unless we mention it, it's the elephant in the room. So, so there are 4 ways that we're different to Verify. 

 

The first is that we're really focussed on the idea that this is for everyone this time. We didn't do inclusion well enough on Verify. We've got a team of people, we've got objectives, long-term objectives and goals in our programme, set around making sure that we don't exclude people. So that's one really big way.

 

A second way that we're different is that we don't have what are called third-party identity providers. So the way that Verify worked is you would have to pick a private sector company to verify your identity. And what it really did was it separated us from all the performance data that we should have been using to improve the system, because all of that was hidden away from us in these third-party companies by design. But it meant it was really hard for us to make incremental improvements to our product. 

 

The third way that we're really different is that we're not taking a one-size-fits-all approach. Verify had a very much all-or-nothing approach. You set the level of identity that you wanted and people either passed or they failed. And if they failed, firstly, the service didn't get any information about why they failed or what they'd passed on. And secondly, the user had to enter all that information again next time around. None of it was saved.

 

So we're experimenting with lots of different ways this time that we can take a much more nuanced approach to help pass across information about the 'was successful' to the service teams so they can pick that up and do their own checks on the service if they need to. And on the user side, anything they've already entered and already passed is saved for any future identity check.

 

And then the final way, which you'll hear me go on about and you are hearing me go on about till I'm blue in the face, is that we are designing with the needs of service teams from day one. So I know we said that it can't all be about what's different from Verify, but it is really important for us to talk to teams about what is different from Verify as a way to show that we have learnt.

 

Helena Trippe:

In terms of the findings, but also I guess what's really exciting from a service design point of view is that we've also been kind of trying to understand, how - within the constraints that we, we need to operate within - so, you know, making sure that we deliver something that's easy to use, that's simple enough, so that it's not too complicated in either for us to build or for service teams to integrate with, having and exploring, I guess, where the identity check might be fitting in within a service journey.

 

So we started to see from the early discovery work, but also some of the prototype testing that we were doing on the product page, how people were kind of trying to understand as well, “well, how do I fit the identity processing, the identity journey within my, within my own kind of service journey?”.

 

But also kind of, again thinking through those trade-offs that they're making. So: “ok, so if I put it in the beginning of the journey, will that create too much of a barrier for my users? Or if I put it at the end of the journey, will that allow me then at least to collect all the eligibility information that the applicant has submitted and then take a view as to whether the applicant can actually go ahead with this particular identity journey or another identity journey that might be available?”. So that, that was really interesting to, to see and kind of see the appetite as well for, for that. 

 

I was just going to add, I guess that, a thank you, actually, for your service teams. I think they've been incredibly generous with their time, incredibly generous with their knowledge. We've, we're learning. And it, and no, no matter how many times you go out to speak to people, you kind of always, I'm always amazed at how, how generous people are in terms of sharing their time, their knowledge and what they've, what they've learnt. So a big thank you.

 

Will Myddelton:

Yeah, I-I-I totally agree with that, Helena. So I think that, from the 50 research sessions we've done with service teams about identity so far, I think there's 3 big questions that we know we need to answer really early on in that service team’s experience of our product.

 

So the first one is: “what on earth is an identity check and how does it fit in with my existing service?” And the reason that's so important to answer is because until we've, like, communicated the ways that our identity checks can fit in, you know, whether it's at the beginning or the end or at multiple points in a service, is really difficult to talk about, like the other benefits of them, right? 

 

As soon as teams understand that, they move on to the second question, which is, “ok, fine. But how do I know this is going to work for all of my users?” And the research that we've done over the last 2 or 3 weeks has really led us to think that there's 3 ways that we need to talk about that.

 

One is we need to talk about how accessible our product and our identity checks will be. But to be honest, service teams just expect that we will do that and we expect that we will do that as well. So that's more of a reassurance than a, a big question. 

 

The 2 things that we really need to talk about and be clear when it comes to inclusion are: what documents people can use - because services are very aware that not everyone has passports and driving licences, so we need to be very clear that our system allows people to use many more documents to prove their identity than simply driving licences and passports - and secondly, and I think the thing that has emerged really strongly from the research, is we need to talk much more convincingly about what it means to do identity checks in different channels.

 

And then the third question that we need to answer, which, let's be honest, is not a question of any service thing comes to us with, but as a result of the way that we're thinking about the product, is: “what are these 3 strengths of identity check or 4 strengths of identity check? And how do I pick the one that is right for my service?”

 

And I think this is the hardest thing that we face because it's quite a weird, abstract thing, these strengths of identity check. Because for each strength of identity check - we, we call them low, medium, high and extra high - you might choose a higher strength if you're doing something risky, like paying out money, and a lower strength if you're doing something less risky, like letting a user view some non-controversial data about themself.

 

But it's really hard to help services see themselves in that strength system because what you're doing in that strength system is you're trading off, like, risk of fraud and risk of security by going higher, but the higher you go, the fewer people are going to be able to complete that check because the harder it gets. And we're, we're really focussing on how we can explain that in a way that makes those trade-offs obvious to users.

 

And I think if I step back from those 3 questions, I think we've learnt something bigger in the last few weeks, which feels like a bit of an 'a-ha' moment for us, which is that the strength of the check plus the document that the user brings and the channel that the user does it in, combines to create a unique user journey for that context. And because it's combinatorial - there are 4 strengths, you might have 10 documents, each of which can be checked 2 or 3 ways across 4 channels - you're talking about hundreds of unique user journeys.

 

And so I think the thing that we've learnt over the last few weeks is that our core challenge is helping service teams understand what is going on with that weird, like, multiplicity of user journeys because they're going to be sitting in the service’s journey. So they need to know, before they even think about how to integrate, they need to understand the implications of those things. 

 

And I'll say, I'll say one more thing that we’ve learnt: there is sometimes a tension between the things that our service team users need and that our job is to resolve that tension. So on the one hand, service teams need widely inclusive identity checks, and on the other hand, in research, service teams expect to be able to do things like specify which documents they will accept or which channels their users can use.

 

But actually, if you think about the user journey, is the result of strength plus document plus channel: the service only gets to choose the strength. Because the user gets to choose the document they have and the user gets to choose the channel. Services can't choose the documents and they can't choose the channels because that widens the inclusion of the product, which is a bigger need for service teams. And we've learnt that there is sometimes a tension between the, the different needs that service teams have. And we're going to have to do a better job of explaining why our product has decided to, to do things in a certain way.

 

Vanessa Schneider:

Well, I was going to ask you, Tom, Will mentioned a bit earlier in his answer that hype is necessary in order to generate interest of service teams. Is this conversation the kind of hype that drew you in?

 

Tom Stewart:

Absolutely. I-I-I love this conversation. I love the process of, of user research from beginning to end. I can absolutely attest to the, to the fun part that Will mentioned. We're having some great conversations with, with GDS and your teams just now. I-I'm particularly sensitive around content, around the language. So I, so I think I've been particularly challenging with some of your content design team about, the use of particular words and things like that. You know, all in, all in, for the best possible reasons, you know, to get the, to get the best result, best product.

 

We've, we've also had some particularly interesting conversations in Defence around that, again, the, the levels that, that we've been talking about. And a-again, I'm sitting here nodding away, whilst Will was talking. So, again, some really rich conversation.

 

To get back to your question, it was about the hype. And absolutely, yep, yep. We've, we've been caught up in that. We are encouraging it. We are, we're helping that, we're helping that, that that hype, we're helping to keep that going basically. I've been involved in this work for some, well really from its inception.

 

And I-I think it's absolutely a vital part of my role that I go back to Defence and I'm really, really quite loud about this work, you know. Anyone that will listen, anyone I think should listen or should know about this is hearing about this work because of the work that we're doing in Veterans UK. The, the, the hype is essential.

 

Vanessa Schneider:

[laughs] Brilliant. Well we're always looking forward to new listeners. I was wondering, how is it that you found out that this work was happening? How did the first contact to the GDS team get established?

 

Tom Stewart:

So, so I was one of those teams where Verify was a, an integral part of our, the technical solution. But we, you know, we engaged uh, with GDS and said, “right, how can we-- you know, presumably you've, you've got something in the pipeline. You know you're developing something new. How do we, how can we help you with that? You know, how can my, how can my user research assist you? You know, how can my Service Designer assist what, what you're doing over there? You know, can we, can we share our work?”

 

Vanessa Schneider:

That makes a lot of sense, it's great to see that the relationship has been such a productive one from the beginning. Well, in that case, Will, Helena, I just want to know, are there more opportunities for service teams to get involved with you? How do they do that if it's the case?

 

Will Myddelton:

I mean, yes, of course, there are. Like we're, we're, we're built on the goodwill of colleagues around government. Our products are only as good as the amount of, like, colleagues that volunteer their time to take part in research sessions.

 

The easiest way is to go to: sign hyphen in dot service dot GOV.UK [sign-in.service.gov.uk] and you'll see the GOV.UK sign product page and there's a big button on there called 'register your interest'. And whether you're interested in just login and authentication, which is what that page is mainly about, or whether you are interested in identity, if you register your interest on that page, one of our researchers will be in touch with you to do a preliminary interview to understand what your needs are, and then we triage that and you will be involved in one of our research sessions that is most appropriate to you and your service.

 

Please get involved. And some of the kind of research that we're likely to do over the next few months: some of it is like concept research - like there's going to be this product in the future, like how do you talk about how it would meet your needs or what wouldn't meet your needs? So that, that's really helping us design what the future state is, which then helps us design all the steps to get there.

 

And we also simultaneously doing research on the authentication products that we have launched first. So that's about like the first use of that as in your team. So if you want to integrate authentication and GOV.UK accounts into your service, you can, we're going to be doing research with people that look at the, the onboarding steps. Because what we've learned from doing these platform products in the past is that: it's not easy to onboard these platform products. And the way that we need to talk about it gets shaped by you know, round after round after round of that research.

 

So yeah, we really value that. And like Tom has said, we think they're actually quite fun experiences to be part of as well.

 

Vanessa Schneider:

Right, brilliant. So you've heard it, folks, get in touch. We've clearly covered a lot of ground already, but I was wondering maybe, Helena, you could start us off with telling us what's next for you.

 

Helena Trippe:

So, as Will suggested, we've kind of, as part of the, the, the research that we've been doing in the past 6 weeks, we've been very much focussing maybe a year, 18 months ahead, looking at the future of, the future state, of the identity product: trying to understand how teams and service teams engage with those concepts to also understand whether we are understanding it in the right way as a programme and have consistency, in terms of what we're talking about, particularly around kind of strength levels.

 

But I think for, for us now, there's a lot of focus on supporting as well the onboarding for the authentication journey, including looking at some of the support models in the service, management models around supporting users and service teams to link up with the authentication side of things and the sign on side of things. So that's quite exciting. I think we're very much trying to explore the extent as well of the self-service kind of model for support and what we can put in place to make sure that people feel supported, but also that it's not too much of a burden for us and service teams to, to be able to deliver that.

 

Vanessa Schneider:

Great, Tom, how about you, where do you see this going next for you?

 

Tom Stewart:

So we, we're squaring up for a Beta assessment towards the autumn this year. Which is very exciting. And there's a lot work going on just now to work out, to, to work out where precisely this work with GDS, where that lands. Like you know, should I, should I postpone the Beta perhaps for a more, for a more complete service or do I just turn up at the Beta with you know, very clear plans as to what my, what my plans are for the future and hope that I can still make a compelling, convincing case that we should be able to go live in the interim. So there's a lot of really rich conversation going on around that just now.

 

And otherwise, the plan is to-to very much pester you and GDS and make sure that we, that we stay as close to the front of the queue as possible, to continue working with you to continue to take your advice, but also hopefully to continue to have some of our advice received in kind. So, yeah, very exciting times for us in general.

 

Vanessa Schneider: 

Well, consider yourself forewarned [laughs] Tom told you he'd pester you. Will, do you want to round us off with what you think's up next for you?

 

Will Myddelton:

So we got a new Director, Natalie Jones, who's joining us in September. And that's really exciting. She comes with a huge amount of experience of delivering really innovative and you know, worthwhile, usable, workable digital identity products with the Home Office. So we're really excited about Natalie joining our programme.

 

Beyond that, identity work goes through its alpha self-assessment in September. So our identity teams are all hyper-focussed on that. A little bit nervous. Little bit excited. Getting people from around government to mark our work is a sign of a robust assessment process. And so we're, we're proud to take part in that. But it is also you know, tough, as anyone that's been through service assessment will attest.

 

And we are going live with the first service that will be using GOV.UK Signin for authentication, and that will be in October. So that's a really big deal for us. And Helena talks about we're focussing on supporting the delivery of that. So we're downing tools on some of our identity concept work for just a few weeks so that we can make sure that that launch goes smoothly because all of our identity work builds on top of the authentication work.

 

Vanessa Schneider:

I have to say, I am really excited by the picture that you're painting, so I can't wait to see how it goes. 

 

Thank you for joining me today on the podcast. It's been really great to hear how GDS is co-designing this work with other parts of government, hearing how it's being received by those parts of government, and just making sure that it's a truly collaborative product that works for all users, whether that's citizens or colleagues in the public sector. So just another reminder, in case we haven't said it often enough, if you are a service team in government and you're interested in becoming an early adopter, or if you work in a public sector service team more generally and want to share your experience for our research, you can visit the product page, that's: sign hyphen in dot service dot gov dot UK [sign-in.service.gov.uk] and you can register your interest. That was snappy. [laughs]

 

You can listen to all the episodes of the Government Digital Service podcast on Spotify, Apple Podcasts and all other major podcast platforms. And the transcripts are available on PodBean. 

 

Goodbye!

 

Will Myddelton:

Goodbye. 

 

Helena Trippe:

Goodbye. 

 

Tom Stewart: 

Thanks everyone. Goodbye.