 My name is Linda. I work for Greater London Authority, GLA, otherwise known as City Hall. I head the development and digital delivery team at GLA, and we look after and deliver the digital services for the Mayor of London and Assembly. I've worked under two mayors. One of them is the current Prime Minister, but that's another presentation for another day. Hi, I'm Will Huggins, CEO and co-founder at Zucha, and we are the Drupal Development Partner that has been working with GLA on a number of projects, and in particular the one that we want to talk about today, which is Team London. The GLA is responsible for the strategic administration of 6, 10 square metres of Greater London. The primary website of the GLA is London.gov.uk. It has so many other associated microsites integrated without the site. The site informs and promotes services of the London Mayor and London Assembly offers the capital. As the work of the Mayor and Assembly evolves, so must our digital services continually engage in users and stakeholders and then beyond London. Team London is a volunteering programme that was started by, launched during the Olympics in 2012 to gain more volunteers to participate and help with Olympics. It has 150,000 adults and 100,000 younger Londoners volunteers. It's one of Mayor of London's initiatives, priority initiatives, encouraging more Londoners to give time and help make the city a better place for everyone. So the challenge, the main challenge was Team London had three separate microsites that are sitting on Drupal 7 legacy website. And the main challenge was to reinvent the user experience of those three separate microsites into a single new and improved user experience to help increase the numbers and diversity of the volunteers that participate through the programme. How many here are working on Drupal 7 out of interest using it? And how many moved to DA? Okay, so this will tell the story of how we did it until London. So we partnered with Zucha and their experience lab user research agency to help us deliver this project using user-centred design. To start with, we first had a full analysis and an audit of the current features and functionality that was offered on the legacy sites, the three legacy sites. And then we looked at what new features that would be coming up in the immediate future. We then, working with our user research agency experience lab, we did collaborative research with representative groups from volunteers, admin, and providers to look together on how we can improve the user experience of Team London, how to make it easier for providers to publicise and publish volunteering opportunities and how to make it easier for volunteers to sign up and perform them. We ran four different workshops with a representative of the admin groups that access Team London and the providers and the volunteers. And we looked at how they interact separately with Team London sites and to try and understand what's their motivations and user needs and frustrations. One of the exciting stories that we keep telling when we tell the story of this project is the ideas that came out of it. It's so simple, but you don't know until you start talking to them. One of the needs of the volunteers was to find the location of their next volunteering opportunity. The legacy site only offered which borough the volunteering opportunity is while they wanted the address. How do I get from A to B to get there in time? And then the motivations, the younger volunteers wanted to gain skills and work skills that they would be able to use looking for jobs while the older volunteers wanted to an opportunity to get back into the community. The main frustration that came across all the participants was they were left in limbo like volunteers who were applying for those opportunities. They didn't have, via the legacy site, information that tells them what should they do on the day, where should I go, simple questions, what should I bring with me. There was no interaction, so this was a pain point for the volunteers that we wanted to address in the rebuild of the site on D8. So we took all the outcome that came from the user research and then we put it together to map out the user needs and journey to rebuild it and take this opportunity to rebuild it on D8. And that helped us put together a minimum viable product that we then worked with Zucha on how do we build the solution, the technical solution behind it and how do we integrate it with the main primary site of GLA, which is London.gov.uk. This was our first microsite to be built on D8, so we didn't have the infrastructure, we didn't have the tools that we needed, so we rely heavily on Zucha's experience to set up that infrastructure and the tools to help move and migrate the data from the D7 legacy sites to the D8 site. Also, help understand how do we enable some of the features that would be used to build other sites and to reuse them as reusable components to help us deliver sites in the future easier. So we prototype the designs for Team London. We tested them with users and presented them of volunteers, admin and providers and to try to get the loop of feedback from the user testing. So we were going into reviewing the designs together, looking at what features and info as in content that we should keep, what we should be removing and what we should be reusing or re-editing and updating. Then throughout the lifecycle of the projects, we ran three different user testing workshops with a focus group of 16 key users from volunteers and from providers to test and iterate as we go and validate the designs sprint by sprint. The information that came from the user testing and the films because we filmed it throughout were used at Show and Tell to engage senior stakeholders and get their feedback. And then the feedback from the Show and Tells and the feedback from the user testing was then validated against the MVP that we've set up to build in the first place and that helped us prioritize sprint by sprint and refine what the next iteration should be and how it should impact the build of the product. Then I'm going to hand it over to you to take you through that technical though. So for the technical solution, there are two considerations. One is to deliver the functionality that was coming out of all of the user research and the user needs work. And the other was to lay the foundations for upgrading more of the London.gov Group of Seven states onto True Plate and really use this as an opportunity to learn and point in place the foundations for that future upgrade. It began with taking the existing Drupal 7 profiles and the state features and porting those to Drupal 8 for the new microsite to ensure that we had consistency across the London.gov estate. We also wanted to make sure that the solution was as maintainable as possible so we really focused on using core and contributed modules to deliver a lot of functionality around content moderation, publishing workflows and user interactions. So to get that kind of consistency across the whole of the London.gov estate, the base theme was built using those GLA estate features that can then be used and rolled out across all future microsites. So again, building a foundation for future scalability and ensuring consistency throughout the rollout of the True Plate upgrades. In terms of functionality, we really focused around accessibility. One of the key goals was reaching harder to reach groups and make sure that the solution was accessible to everybody. So again, a lot of the front-end efforts certainly focused around accessibility and also performance. So this is definitely a service that volunteers in particular use very heavily on mobile devices. So making sure that it was performance, that everything loaded well and it used the minimum amount of resources to deliver the experience that users really need. Kind of mentioned earlier, one of the key frustrations that came out from the research was the previous system had really guided users around searching for opportunities by the borough in which they lived. But actually that was kind of irrelevant to a lot of users. They said, well, we don't really care if it's in our borough or the neighbouring borough, we're more interested in where it is, how easy is it for me to get to, how long does it take to get there. So we really focused on delivering a really enhanced search experience. So using Apache Solar to be able to pull in all of the location information and serve the results not just as a list of opportunities but also in a map view where people can literally visually select the most appropriate opportunity for them. And also within the search results provide distance and travel details. So really everything they need to know about how to get to the opportunity and how long it will take them to get there is right there at the search results list page. Some custom features that were really important. Again, one of the things that kind of mentioned was the frustration of volunteers being in limbo. So that's the time lag between saying, yeah, I want to go and volunteer on this date and then not hearing anything back. And in that time maybe don't make other plans or get a bit disillusioned. So having used the dashboards that both volunteers but also the administrators and providers of the volunteering opportunities were able to manage all of their information in a single easy to use screen. And again, focusing on the mobile UI was a really important factor in this to ensure that the system is usable across all devices. So that people can manage the opportunities they've got and the volunteers that are coming to them. And a key part of that, which we added in as a direct result of the user research is having SLA notifications. So when the user's action things, so for example, if I'm a volunteer and I volunteer for an opportunity, the administrator will get notified and there'll be SLA's around that. If they haven't responded with a certain timeframe, they'll get a reminder. And it's really just about reducing that lag between someone saying they want to volunteer and then actually getting the confirmation that they're wanted and what they need to do. One of the things that we've really enjoyed about working with GLA is that they are really passionate about making sure that we're open sourcing all of the work we do. So it's used not just by other London boroughs but by any organisation that has similar challenges or user needs. So a lot of the project code is already made available in GitHub and as we develop more functionality, we will continue to add fuller release information for everyone else to benefit from the learnings. Team London was delivered by a joint team from Zucca and GLA staff that worked together using the Agile methodology and we were adhering to government service manual design. As a result, we undergone two local government digital service assessments and we passed both of them with blind marks. So the first assessment was after the discovery and it was about the discovery and the user research work that was delivered via the pollock and then the second one was after the launch of the beta site and they are blogs about them on London.gov if you want to read more. And it's just a photo to prove that we actually did all work together nicely. So in terms of the outcomes, it's been not just a pleasing project to work on from the perspective of the user engagement factor but also it's actually worked. So since launch in July, visits have increased by 14.4% but most importantly for us really it's the engagement on the site. So engagement which is kind of measures dwell time simplistically for this statistic is over 34% and bounce rates down by over 23%. So we get much better engagement of users on the site and that's manifesting itself in actual searches for opportunities. So in the five months since launch we've had almost 400,000 unique searches which has resulted in over 10,000 registrations for volunteers to actually register and also for providers to register their opportunities for volunteers which is a 6.7% conversion rate which has exceeded the expectations that we had initially set for the project. So in summary the project really has followed the model of starting with the users really understanding exactly what the users need and building a service that's based around those human needs, motivations and frustrations using agile iterative model and working as a single agile team with shared purpose and coding in the open and making everything that we do available for everybody else to use and hopefully they will. Any questions? No, it's English. It's something we're looking into for our digital services at the Greater London Authority. Currently all of our digital services are in English only. Is there a link to the... There isn't but would you be happy for it to be published on or circulated? Yes, we'll circulate it, we'll make sure it's published so you can have a look at it. You're welcome. What was the reason for it not being multilingual from the beginning? I think it's because of the work that we do and the resources that we have in the team. All our digital services currently it's only provided in English only but like I said part of the move to D8 is to improve the work that we do and that's one of the aspects that we're looking into. How to do it? It is a part of your... I mean I guess you're starting to use all the digital presences of the GLA I mean I've taken an internet with maybe a different set of requirements that's what you use for all the web presences that you might have. Mostly through most of our work, it depends on the project requirements so like I said the primary site for the GLA at London.gov.uk we have a vast number of microsites and it depends on the user engagement and the requirement of the product so the technology currently is mainly Drupal, a little bit of Java we have, yeah it's Drupal and Java so far. You don't consider any other content management systems for instance or you have any other legacy systems that have been migrated into Drupal? The current London.gov originally was in Drupal and it was built into 7 and now the aim is to move it into D8 but we don't have anything that is not in Drupal or not Java. We like WordPress for example, we don't have any product using different CMS now. Welcome. There could be but not run by the GLA because we have two different types of projects so we have projects that we build for the GLA to allow engagements over our policies that we work on and then there are projects that we partner with other partners, GLA partners like NHS, Metropolitan Police, Education of that and then if we are partnering with them then we use their platforms so there might be other platforms that we are partnered with where they have our brands because we work together on that are not non-Drupal but not the GLA digital estate now. Any other questions? Just one thing that I thought about which goes to answer the question about multilingual. One of the issues that we found on other projects where there's a heavy amount of the content is user generated and this is a perfect example. All of the content really is generated by charities and organisations that are seeking volunteers. To make it truly multilingual we would have to try to encourage everybody to post every opportunity in the various languages that we would choose to publish which adds another layer of complexity to the process of planning how we can do that. So it's definitely something that's worth noting because London more than probably any other city in the UK is a multicultural environment so it's what we want to consider I think. Thank you.