Government Digital Service Podcast #34: Collecting information from users
Our Collecting Information From Users team and a guest from the Home Office share how we’re helping people in government to create accessible, affordable digital forms.
The transcript for the episode follows:
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, I’m chatting with colleagues about our work supporting teams across government that collect information from users using online forms, paper forms or a combination of the two. We've been partnering with other government organisations to investigate how they're currently collecting this information and what kind of help they might need. Because right now, almost all of the forms on GOV.UK that have been downloaded around 7,000 or so times are PDFs or other document-based forms. Usually they are inaccessible, hard to use, and on average teams spend 8 minutes more on processing the information they collect, compared to online forms. This is bad for users, and also bad for government, as it’s inefficient and misses opportunities for using the data for analysis. Worse, these kinds of forms are growing by approximately 6% every year and we estimate it would take the existing form-building service teams more than 70 years to convert just the existing PDFs into HTML forms.
So I’m joined by Harry Voss, Senior Product Manager, and Moyo Kolawole, Senior User Researcher, from GDS, who are part of a team working on a solution that will make it much easier to digitise existing forms, and make it simpler for people in government to create new digital forms - even if they don’t have technical expertise. I’m also joined by Suzanne Mycock from the Family Policy Unit in the Home Office, who has been contributing to the research our team is conducting.
To kick us off, Moyo, would you please introduce yourself to our listeners?
Sure. Hi I'm Moyo Kolawole. I'm a Senior User Researcher on the Collecting Information from Users team at GDS.
Great, thank you. Harry how about you, would you please introduce yourself?
Yeah, sure. Hey, folks, I'm Harry Vos, I'm a Senior Product Manager at Government Digital Service. Um, I've been around for like 4 years or something, err, and, err, yeah I’ve been looking at forms and how people collect information from members of the public and businesses, err, since December. So I've been really lucky to be working with some amazing people across government. Thanks for having me.
No worries, thank you. And finally, Suzanne, would you like to introduce yourself as well, please?
Hi there. My name's Suzanne Mycock. And I'm a Guidance and Forms Editor. I work on the Guidance Rules and Forms team, part of the Family Policy Unit within the Home Office. Err, our team manages 3 of the main tools needed to implement policy, all of which are vital for caseworkers and customers. So that's coordinating secondary legislation, managing guidance and managing application forms.
Suzanne, as I mentioned, there is a mountain of work to be done to improve forms, but maybe it would help listeners if you could start us off by explaining how the process of creating or editing forms works for you?
So for us it tends to be led by policy teams, so if a policy changes or if a new policy comes into play, sometimes they'll need a, a form to to support the work that they're doing to collect information from end users or applicants. Now, it's not just a case of a policy team coming to us and saying we need a form, we need a paper form, can you go away, create that for us? It’s kind of bigger than that, because it depends on a number of factors.
Many of our forms are now on GOV.UK, they’ve been digitised and, um, that they sort of stand for quite a number of the forms that we used to, we used to be responsible for. Um, that number has has shrunk. But as you just said a few moments ago, we are sort of being asked to create sort of bespoke forms, um, for low usage routes, really, or forms that may not need to be around for years and years. It might just be to suit for a short term policy or a, um, intermediary policy.
So what happens is a policy team will come to us and say that they need a form. Um, we will then take that to a board and it is up to the board then to decide whether the form will, um, exist as paper or whether it will be digitised on GOV.UK. Um, and as I say, err, that decision basically comes down to the cost, the usage and how long that form would be needed for. So it's kind of, it's all kicked off by policy and rules changes and policy changes. And then if it's decided that, yes, it's it’s suitable to go, err, on a paper, paper form, the policy team will come to us with a basic set of questions that they want to ask, the information that they want to extract from from the applicants. And we will then go away and we'll put that onto, um, our software.
We'll try and build them a form as best as we can that meets accessibility needs, because that obviously is our number one priority, making sure that everything that we produce or try and make sure that things that that we produce going forward is, um, now and going forward, should I say, is as accessible as it possibly can be. Although we do have, sort of, some legacy forms, um, that are based on paper and can only be printed out and filled in by hand.
The, the work that we have on forms tends to come in sort of peaks and troughs so we can be extremely busy on forms, um, or we can have no work to do on forms for, for a while, because as you're probably aware, we don't just work on application forms, we sort of cover a wide spectrum of work than than just application forms. But it tends to be driven largely by things like policy changes. Now, they tended to happen a couple of times a year, but just recently we've sort of had, sort of several changes, um, throughout the year. So, um, we've sort of had a few, a few peaks this year and sort of late last year, err, for various reasons.
But again, it depends on the sort of the, the extent of the changes, because sometimes they're very minor and it could just be changing one question, err, which takes no time at all, or if it's a case of building a brand new form, um, that can actually take with some of the software that we use, um, believe, err, to like, can take a good sort of three days to, to build and pull the accessibility text behind that.
And the reason it takes so long is, is partly because the, the software that we currently use is no longer supported. So it's becoming slower, more clunky, more difficult to work with, and, um, it's very unstable. Err, so that sometimes means that if it's not behaving like it should, it can take us a little bit longer. Err, and of course, it depends how long the form is as well, so if it's a brand new form sometimes it can just be a couple of pages. Other times it can be a 40-page form. Um, so it, it depends on, on those different factors, really.
Policy are the ones who inform whether, whether a form is needed. Um, and policy teams will work with legal representatives, obviously, to make sure that the content of the, the forms is, um, sort of legally upstanding. Um, but it will also work with operational staff to make sure that the, the form is capturing the kind of content that they need to be able to process application forms. Um, and then decisions are also made by the senior management team when it goes to the board to decide on whether it's going to be paper form or whether it's going to be purely, um, digitised. So it's, um, it can be a very sort of fast moving environment, err, depending on sort of the, the nature of what it is we're involved with, because obviously we've been involved with some sort of high profile areas.
I'm actually curious to hear what you think works about this process and what doesn't.
I think for, for simplicity purposes, the process works quite well. People know, err, where to go to, to, to ask about forms or to ask for changes or new forms. Um, so I think that works pretty well. People know, um, where they can get that information from.
When people do want changes to forms, it's quite a, err, cost effective way of, of making those changes because we don't have to go to a third party and ask them to make those changes. We can actually physically do it on our team. So it's a cost effective and easy way to make and maintain forms.
I like to think that we are sort of continually striving to make sure that we produce accessible forms, um, accessibility to, to us is obviously ensuring that a, a product is available and can be used by everyone. Um, so that would mean that people with certain conditions or disabilities can access exactly the same information as everybody else and that it is easy to access and to use. And it is something that we are aware of, um, and we want to get better at, at doing that.
We try to talk to specialists. So, um, accessibility specialists in the department and sometimes in other government departments as well to sort of try and glean best practice from them. Um, we are aware of our responsibilities under the accessibility regulations, which is why really we’re, we’re keen to get involved with this project, because the more we can do, err, to make our forms accessible, the better, because we just want to create a service or a product that is going to work for everybody and to take our responsibility seriously. So whilst we may not be 100 percent there, I think we've sort of certainly got the, the ethos on team to to and have the desire to want to be there. And we are happy to engage with anybody who can help us get there. So, um, I, I think we're, we’re doing OK, but we could do a lot better.
That makes sense. I was actually wondering, Moyo, you've been conducting a couple of research sessions. Do the things that Suzanne is highlighting chime with what other people on panels have said, or are the responses very varied across what works for them and what doesn't work for them when creating forms?
I think a lot of what Suzanne has said has resonated, um, a lot across the different form builders that we've been able to speak to across government. There’s this real desire to be able to fulfil these accessibility kind of guidelines, um, the 2018 accessibility guidelines. But there is a lack of kind of like time or a lack of, um, knowledge around how exactly to do that. And I think it’s, err, a barrier, like the process of creating accessible forms or knowing what to include to make forms more accessible for, for instance, um, users who might have visual impairments and therefore, you require screen readers to access information how to best design forms for them. There's, it's almost like, a lack of knowledge around how exactly to put it in practice to be able to fulfil these, um, WCAG 2.1 AA guidelines.
And so I think there's a real desire for a solution that not only tackles the problem of inaccessible forms, but also helps kind of upskill those who are creating the forms, um, to learn more about how they can also, you know, be better at thinking with accessibility in mind while designing. Um, so I think a lot of what Suzanne has said has definitely come out in our research.
Well, it makes sense that others feel the same way. Um, I was wondering, Harry, there are clearly common themes that are emerging. I was wondering if there's anything that you have a bigger picture on, err, besides potentially the accessibility point that, um, that really speaks to why this needs tackling.
So, I mean, our vision being that every single form on GOV.UK is, err, accessible, easy to use and quick to process. And it's in that order, really, I suppose, because accessibility is, is really about, um, people's, err yeah, people's rights under the Equality Act and people, you know, not being discriminated against right. How do we make sure that everybody can complete these forms first time, err, not sort of like battle through this thing that is really tricky to use and get stuck and we've got to call up because I don't know I don't even know what question you're asking me here. I don't actually have that information.
So there's this whole, whole thing that's kind of like around this form design and then and then also about like sort of speed of processing, a lot, we hear from a lot of teams that, um, you know, so many forms come in, err, to to their to their team inbox or, err, to to their in, in, in some circumstances in their post tray, err, and and and the forms don't have the information they need to make a decision about that person or that business or that sector.
And, and so, you know, it was kind of interesting to pick up on what Suzanne was saying around, you know, the policy role as having to work with those operations teams to actually understand like what is it that you need to make that decision about a person. And I suppose if we can if we can speed that up, um, you know, just simply through making sure, does does that form have everything they need to make up the decision, um, err, through you know, the things like sort of validating that that the information that is submitted is is is in the format that we would expect. Um, so if someone has put, err, the, the date of application instead of their date of birth, you know, is that something that we can we can be like, oh that's a really obvious thing. Like, um, well, let's let's fix that.
So we should see some improvements there as well. And, and, and we reckon, err, just through some, some simple changes to, like, how the information gets collected, should be able to speed up, err, things by, on average 8 minutes per per form and in terms of that just having the right information to make the decision. Um, so it's going to vary from service to service and from form to form. Um, but there's some kind of big improvements we want to make there.
I was wondering if you could talk to us a little bit more about the scale of what you're trying to tackle here.
Yeah, it's a it's a it's a big it's a big challenge. Um, I’m not going to lie, err, there’s, there's over 5,000 form pages on GOV.UK and, and each of those, err, can have, you know, any, anywhere, anywhere from between sort of one and in some cases hundreds of of of different forms attached to those pages. Um, so it's a really big, err, challenge.
And and and like you mentioned at the start, um, most of them remain solely as sort of document-based forms, err, which, err, you know, which despite everyone's best efforts, sometimes do you have accessibility problems. And so, um, yeah, it's a really big, it's a big challenge. And I think it's something that the appetite is there. So you know we heard, you know Suzanne you’re mentioning you know you really want to you and your team have got accessibility at heart and you're thinking about how to make this service as easy as possible for people to use.
There's lots of teams that, that that sort of want to do the right thing, err, and, and, and, try and improve those forms. Um, but, yeah, sometimes the sort of software isn't always there, um, for people to sort of, err, to to make those improvements. So it feels like a good opportunity. And yeah, we're hoping that, yeah, if you're if you're listening and the, this issue resonates with you, you know, we'd love to hear from you and find out how we can help you and partner up as well, um, because this is not something that the Government Digital Service can just solve ourselves, we're not just going to sit here and magically make this problem go away. Err, you know, we need, we need to sort of come at this together as as government collectively. So, yeah. Really keen to sort of meet and meet new people and and and listen and and find out about your problems.
It definitely feels rewarding being the convenor of this kind of work and, and trying to get everybody, err, around the table on this issue. I was wondering, how are we approaching this process? Obviously, um, we’ve, we've been doing some research. That was the discovery phase. What else, what else is happening?
So, um, after we’ve kind of wrapped up our, what we call our sort of discovery research, so trying to understand more about this sort of problems, and whether this is something that our organisation is well positioned to actually affect, um, we kind of like concluded like, yes, this is a problem, that it's not going to sort of go away, and also that, yes, we think we can affect it.
So now we're really in that stage of, OK, we know that there are different ways of, of, of creating a form. Um, and, you know, we have a hunch that, um, online forms that are using, err, sort of web browsers to sort of complete forms and things like that, err, can be more accessible than, err, some of those document-based forms. Err, and that you can do that in a way that doesn't demand that the person creating that form has a sort of strong accessibility awareness because, um, well, Suzanne’s team, like you've got lots of, err, accessibility awareness. Um, sometimes the software isn't, doesn’t always help with that. But, um, there are other teams that are maybe more sort of policy specialists and, and, and people who’re trying to really understand, like, OK, what are the decisions that we want to make about people, err, to, to sort of provide them with some sort of public good, some public service, thinking, maybe more in that sort of like the sort of policy intent space. Err, and, and, and, won’t have those sort of specialist skills. And that's, that's kind of like that, that that should be fine.
And and I think that's the thing we really want to test is, you know, can we provide, um, better, better tooling to, to create those forms, err, without having to to demand that everybody is a specialist, err, designer, or accessibility person or um, that sort of thing. So, um, yeah, we've got a bunch of different, um, prototypes, if you like, of, of different ways of creating forms. Err, and we're going to be working with, err, people like Suzanne to try and sort of test out, OK, if we if we're using this this way of making forms versus the existing way and also what effect does that have on the quality of the forms and the accessibility of the forms, their ease of use, err, that sort of thing, so really excited to sort of start testing these.
It's, it's one thing to sort of try and understand the problem and do that sort of user research and that data analysis in that sort of exploratory phase. But now, when we’re, like, starting to test things, we can say things, like, actually let's - before we get too carried away with it - let's actually find out if that's going to work. So for me, that's the really exciting bit.
Really our goal is to to to compliment some of those existing forms, err, with with online forms that can be completed in a Web browser, err, on on a phone or, or anything, you don't need a printer, don't need any sort of special software to sort of edit it and start completing that form. That's, that is the goal. But, um, in 2018, err, 10% of the UK adult population, err, weren’t using the Internet. So there's clearly a whole bunch of, of people that we must support, err, and continue to support with, err, the existing forms that, that might be more designed around, err, print use.
Yeah, Moyo, so Harry's obviously giving us this big overview of what will, what will come up, I was wondering how do you then in practice carry this work on?
Yes, so we're doing some really exciting kind of user research. Um, I think there's a real need to understand our users better.
And one way in which we're trying to do that is like Harry’s saying, testing out these prototypes and kind of seeing behaviour in action: Can our intended users actually even, um, use these ideas that we've come up with in our team huddle and think this will work. Does that actually work in practice? And so I'm really excited to start kind of testing out behaviour in action.
And the way we're doing that is by setting up, um, a research panel of form builders across government with a variety of experience. So if you’ve touched a form once in your entire professional career or you’ve, you’ve just like spent 3 to 5 days working on forms in a given period, like we want to speak to so many different types of civil servants across government who have this, um, experience with form building to become like part of our panel. And our panel basically looks like, um, just being an ongoing research partner with us. When we, err, come up with these ideas, coming in like ripping it to shreds and being like this wouldn't work for this reason because our team is structured in this way or this sounds like a really great way of meeting this potential challenge or I like this idea, but let's reframe it in a different way. I think those people, everyone has a part to play in product development, not just people whose job title kind of reflects a DDaT role. So by DDaT I mean Digital, Data and Technology professionals across the civil service.
I think everyone - from the users that we're intending to solve the problems for, up until the team who are creating the product - have a part to play in, like, kind of, like, defining how this product, um, develops. And so in our research kind of sessions that we’re planning out, we’re testing out some of our riskiest assumptions, um, things that could really like test our product when we come into development, um, things such as do people even need a form builder? is one of our riskiest assumptions that we need to test.
And this is a time to do it in our alpha phase, where we've understood that there's a problem and we're trying to now understand what the solution to that problem is going to be. We, we’re making sure that we're being really kind of broad and wide in our thinking of how to solve the problem, but making sure that we're trying to solve the problem with our users in mind. And that comes right back down to ensuring that our research sessions are really kind of, like, full with people who have a variety of experience, who have a variety of, kind of, like, knowledge around the form space to really help us understand what works and what doesn't work.
And I think one thing that for me is quite exciting due to my background is that, um, this is also a behaviour change project ultimately. It's not just product development. We're trying to understand how can we shift people away from doing X to do Y. And I think a lot of the time what came out in this exploratory research is that, established ways of working are really like kind of confined and that ultimately like kind of impacts how people create or view the creation of forms. And so if we are trying to create a product, we don't want to just slip into established ways of working.
Why would we use a GDS, for instance, form-builder or something that GDS promoted for us to use? We need to ensure that people understand, like this is why we believe this tool is better to use for form creation than this tool because of these reasons. And this is what, how we think it will help you in your ways of working. And so we also need to do some kind of thinking and research around how our users behave around form creation and what we can learn about how we need to kind of like create, um, interventions or triggers or nudges to encourage people to change their current ways of behaviour with the view of accessibility in mind. Um, and so we're doing kind of really interesting parallel research at the same time, we've got that testing, but we've also got that behaviour understanding, um, element as well, which I'm really looking forward to.
So you mentioned the alpha phase. Do you mind just telling me quickly, what does that refer to?
Yeah, sure. So in any kind of product life cycle, you split it into the discovery, alpha and then beta stage, um, and the discovery stage is mainly where you kind of explore the problems faced, you have knowledge that there is a problem. You're not quite sure exactly what it is. You're using that space to explore all the different facets of the problem before coming down to, OK, this is exactly what problem we're going to tackle, um, going forwards. So the alpha phase, um, is when you take that problem that you've identified and you start kind of concept testing solutions to that problem, you're not defined to, um, a specific solution. And it's all about kind of like using that space to explore different ways to solve the problem that you've identified in that discovery phase, before moving onto the beta stage where you're starting to test out some prototypes that you probably defined normally in that alpha stage of how are you going to, like, solve the problem. You start testing out with private, um, partners or collaborators who can give you ongoing feedback about how your product is doing and to solve that problem. Um, so that's really what an overview of the kind of product life cycle is. Um, and so when I say we're in the alpha phase, we're in that stage by where we’re, we've got the problem, we understand the problem space a lot more. But now we're trying to, kind of, idea around how exactly to solve that problem.
No, it's really wonderful to get an insight into how methodical your approach is. I hope that's very comforting to people who haven't even heard about this work that it's ongoing and who are interested in contributing to it. Like both Harry and Moyo have mentioned, if it sounds like this might help your service team, why not get in touch with us and help us in building a solution that will work for everyone. It doesn't matter if you are in Digital, Data or Technology, Moyo did say, um, if you have anything remotely to do with forms, this could benefit you. This does bring me to Suzanne. I was wondering how it was that you became involved with the GDS team. What convinced you that this was worthwhile doing?
I think for our team, I, I, I'd like to think that we, we want to be an exemplar, um, as far as sort of forms creation is concerned. Um, and I think I kind of, sort of, said to, to Harry at the time, it was music to our ears, because the more help we can get to create the forms that we want to create, that the better, really. Um, and we sort of looked to, to people such as Harry and Moyo and, and various other colleagues who have more experience than we do and who probably, um, are better placed to, to tell us what, what we need to do to meet accessibility requirements.
So to work with, with you is, is absolutely fantastic for us because it just gives us, at the end of the day, it’s going to give us the confidence to know that we are producing the right kind of forms for the people that use them. Um, and that ultimately is, is our goal.
Thank you. Um, so to take things back a couple of steps in time. This isn’t new work. Technically. Harry, I think you know a little bit about the history of this. Would you mind sharing with listeners why this is different?
Yeah, for sure. Like I said, I've been, I've been looking at forms since sort of December time, but there are a whole bunch of people that know way, way, way more about forms than we do. So, yeah, whether, yeah, it's learning from Suzanne, whether it's learning from, um, the amazing group of people in the cross-government form building community. So, so people that have been, you know, testing out different form building technologies and approaches that we can learn so much from.
So and and and going back even further there was a team at the Government Digital Service called the GOV.UK Submit team, and they were also looking at sort of similar problem, at around how to how to sort of tackle all of these these these document based forms on GOV.UK and and make them much easier to use. And sort of quicker to process. I think, I think there's a couple of things that that, err, that we can sort of, err, many, many things we can learn from that community and that group of people, if you like.
So one thing is the actual way that form building works on a sort of technical level of how do you configure the questions and how do you make sure that once you've done that configuration, the resulting form is accessible and easy to use and quick to process. A lot of that really hard work’s been done. And so we can sort of learn from, from all those teams, which is just, yeah, we're extremely grateful for.
Some of the technology that they’ve developed is, is, is really, like, advanced, err, when it comes to sort of building accessible forms. And we think that, um, although that might be targeted at, err, sort of digital specialists as the users, if we can take advantage of of some of those technologies and but make them sort of simple enough for for for someone who isn't a sort of techie person, err, to use. Um, we think that there is a lot of benefit we could get from sort of reusing that. Um, so as opposed to us just starting completely from scratch. So then that way I think we're very fortunate.
That's kind of great for, for somebody like me to sort of hear, because we're often deemed to be forms experts and we're not because we don't you know, we're not specialist designers. And sometimes it can make you feel a little bit exposed sometimes, when people come to you and expect you to have the answers for everything and to be able to build something um, when we're not really equipped with the right, err, sort of knowledge to do that, we're not really the experts.
So if, as, as Harry's kind of said, we could sort of pinch bits from from platforms that especially designers do use and make it, um, simple to use for people like myself who who don't have that specialist knowledge, but people come to, to create the forms, that would put us in a very sort of, err, good position really, um, and give us a confidence as well to know that we can use this the software and equipment that we've been given. But neither are we sort of expected to be sort of a specialist designer, or a specialist as such.
Suzanne if, if it’s, if it's any consolation. I studied design for, for like four years, err, and I still don't know my way around some of these softwares are just really quite complicated and, err, and then and then we try and sort of use that for forms because it's the sort of best thing we've got for now, like that it's always going to be a little bit of, err, a strange transition. Just kind of reflects moving from sort of paper to digital, if you like. So fingers crossed we can find something.
I suppose that where things are slightly different is so since the GOV.UK Submit team, um, the accessibility regulations sort of came into force the, sort of, following year. Um, and, and I think that's really sort of changes prioritisation, if you like, um, because whereas before the focus was maybe on the sort of efficiency side of things like can we reduce the waiting time to hear back about an application or whatever government service they're trying to access. That might've been sort of the goal back then. It is still sort of one of our goals, but I suppose, it’s kind of looked at things in a broader perspective. So when you broaden things out, you start to look at, um, you know, some of those lower volume services as well. So, um, you know, a lot of the Digital teams, they’re typically working on some of those higher volume services like get a passport, things that are sort of very commonly used, you've got some brilliant digital teams across government behind them.
You go down a little bit and so you start to look at sort of under 100,00 transactions per year, you start to go down into that sort of median volume bracket. And then there you've got some sort of digital teams maybe working on something for some of the time. So just to sort of roughly explain that model. Um, you've generally got a technology platform that does the sort of form building, but actually that is designed for specialist designers and user researchers, err, and developers. Um, that's a platform that then supports a team of people to then go and support the policy and the operations teams that are going to be designing and running that form, providing a service to them. And that's just like a really brilliant model that works fantastically for those medium volume services. You're going to get something like that that’s, that's really easy to use, accessible, quick to process. That, that's great.
But unfortunately, that approach is still too expensive for the vast majority of services because the vast majority of services are actually quite low volume. So you've got a lot of, sort of what we might call, like, niche, niche services, but, um, like “pay tax as a minister of religion” or “apply for an exemption for, err, electronic waste”. Err, yeah, this is kind of like fairly like specific niche services the government has to provide, and, and that ultimately won't ever be able to sort of afford like a full digital team on them, or even, a sort of a digital team for sort of part of the time. And so it's like, okay, that's the majority of government services. What can we do to help, help those teams take, take advantage of, of online forms and things like that with those goals of accessibility, ease of use and speed of processing in mind.
It's true, our government services are for everyone. So don't be shy, listeners. If you don't work on forms, maybe you know somebody who does: get in touch with our team. How can they get in touch with you? How do they get involved with this?
That's a great question. Err, our team email address is email@example.com Now that's a real mouthful.
But yeah, we're really keen that throughout this entire process of kind of concept, testing, product development, et cetera, we’re really collaborative, um, with a whole variety of people, from people who are just really interested in what we're doing and those who have any sort of experience in this whole form creation process across government, no matter what your job title might look like. So we'd really encourage you to get in touch and keep up to date with what we're, we’re doing, if you have the relevant experience. And also just like super interested in our work, we'd love to hear from you and learn from you, um, as we go through this entire process.
All right, so thank you to our guests for joining me on the podcast, as it's such important work to tackle this challenge and supporting your colleagues across government who may not have that much resource or knowledge, as we just shared. Just to remind listeners, again, if you work on a service that requires information from users and you use forms to collect this information, please get in touch with the team so we can ensure that the solution works for you, too. And if you like this episode, you can listen to all other episodes of the Government Digital Service podcast on Spotify, Apple Podcast and all other major podcast platforms. The transcript is also available on Podbean. Goodbye.
Thanks for listening.
Thanks for listening, bye.
Government Digital Service Podcast #36: Maps in services
Government Digital Service Podcast #35: How our Site Reliability Engineers migrated GOV.UK Pay
Government Digital Service Podcast #33: Digital identity - working with government services
Government Digital Service Podcast #32: Technologists at GDS
Government Digital Service Podcast #31: The vision for GOV.UK and the roadmap to get there
Government Digital Service Podcast #30: Tom Read talks GDS’s future strategy
Government Digital Service Podcast #29: Role of Product Teams in Greener Delivery
Government Digital Service Podcast #28: Demystifying GOV.UK PaaS
Government Digital Service Podcast #27: Clinically Extremely Vulnerable People Service
Government Digital Service Podcast #26: GDS Quiz 2020
Government Digital Service Podcast #25: GOV.UK Pay
Government Digital Service Podcast #24:Celebrating Black Excellence in Tech
Government Digital Service Podcast #23: The Data Standards Authority
Government Digital Service Podcast #22: Content Design
Government Digital Service Podcast #21: The DDaT Fast Stream at GDS
Government Digital Service Podcast #20: Celebrating 2 years of the Local Digital Declaration
Government Digital Service Podcast #19: A spotlight on GOV.UK Notify
Government Digital Service Podcast #18: GOV.UK‘s initial response to Coronavirus
Government Digital Service Podcast #17: International Women‘s Day
Copyright © 2006-2021 Podbean.com