RECORDING: This meeting is being recorded.
FRASER: Rather a formal announcement, wasn’t it? Morning everyone. We are just going to wait a couple of minutes until everybody has joined. I cannot see who is joining at the moment, Annie. Can you give me a heads up when it is looking like it has stabilised?
ANNIE: I think I might have the same issue as you, in that I can see about five at a go.
FRASER: Yes, that is it for me, yes.
ANNA: No worries. We have about twenty people in, so whenever you want, we can start, and I will keep letting people in as they arrive, if anyone is late.
FRASER: Perfect, thanks Anna. Just to warn anyone that is on the call that has joined already, we are recording this session. So, unless you want to be an internet sensation, feel free to turn your cameras and microphones off now. If you do have a question, feel free to (unclear).
Just a quick agenda that we are going to run through this morning. We will introduce myself and Annie in a couple of minutes. To give you a run through of the Repairs Online project as it has been so far, why it came about, and the learning that we have taken. Then we will jump into how a user-need focus changes what we design and build. Although this is focusing on Repairs Online, it’s not so much about the Repairs Online process itself, we are just using that as the case study in this. Then we can go into considerations and results after the user research rounds. Then we will open the floor for questions and discussions from yourselves.
We do want this to be quite an interactive session, so do please feel free to drop messages into the chat or raise your hand if that’s possible on Zoom. If you want to you can turn your camera on when you do have a question.
Annie, did you want to introduce yourself first?
ANNIE: Hello. Like it says, I am one of the User-centred Design Principals here at Made Tech. I come from a local government background. I worked there for about eleven years, both at Brighton and Hove and at Croydon councils. My battery is about to run out so I will handover to Fraser.
FRASER: Perfect timing. Good morning, everybody, well, afternoon now. I am Fraser Trickett, I am a Client Partner with Made Tech. I have only been here about four months but prior to that, I was just shy of 21 years in local government, believe it or not.
I have worked in a whole host of different sections within there but latterly I was the Product Owner for the DLUHC funded Repairs Online project. I have stayed close to that despite moving across to Made Tech. I am just going to run through how this workshop will work.
We are going to give you that overview of the project, discuss what people found from the user research. As already mentioned, we would really like to hear from you for this to be an interactive session. Please use the chat, ask questions, or raise your hand and we will get back to you.
You are free to turn your camera on, but just to reiterate again that this session is being recorded. We will provide some feedback at the end. It is being recorded, for the final time.
I am just going to take you through the Repairs Online journey that we have been through. Just to give a bit of project background, it started back in 2019 when I did the first application to run a discovery to what was at the time HCLG. We have worked with the variety of councils that you can see on screen throughout the life of this project.
This is now part of the continuous funding model. Hopefully, we will be entering into the next round of funding soon. The live partners as it stands today are still Lincoln, who are live with the product, and Newark and Sherwood are the development partner at the moment, and they will be launching later this year with some new features that I will come onto in a just a bit.
Why did we start off looking at Repairs Online? For all the partners that we have just looked at, it was the number one reason that customers call us. It is a complex service. The take-up is low for digital online self-service for this. There were complications around diagnosing the repair. A really important one is that the products that are out there at the moment all tend to be designed around the councils and the back-end system’s needs. SORs are a big forefront in the way things are diagnosed. Expecting some of the most vulnerable in society to understand what millimetre pipe they have got going to their tap. What type of tap they have got can be quite a big ask.
We wanted to do something that was really nice and easy to use, and flip that thinking around so that this was designed around the needs of the user. Also, to make something that was reusable for other authorities, as well. Which leads me nicely onto the vision that we set out at the beginning of this project.
That was to design and build a reusable and – really important – accessible tool that allowed online reporting, that customers preferred to use as it meets their needs. A tool that would be integrated for open, scalable, and accessible APIs, with various scheduling system. So that it can be used by as many authorities as possible. I will pause that last paragraph for now but just come back to that top one.
It really stayed a focus, and continues to be, that whatever we are designing on this, the user needs are first and foremost in it.
Where have we got to so far? After a discovery, two alphas and a beta, we have a common service pattern agreed. That was based on lots and lots of research with customers and with the authorities, getting lots of data out of there.
We have gone through four iterations of the product. We are now entering into our fifth. All that has been based on that user feedback. We have really tried to test with a wide range of users during that time, as well. That includes digitally excluded, and those with some difficulties.
We have got a working integration into the scheduling software. We have been able to make something that is responsive, so that it is nice and accessible for everybody. We’ve had really good success measures agreed through the theory of change, as D:Luck fondly call it. That means that we can quickly see the effectiveness of the product that we are implementing.
It is great to have the NVP service live at Lincoln. That has been running for a fair few months now. They are just going through the process of starting to promote it. There has been a real upshift in take-up without any promotion. There are around 20 percent of customers now reporting repairs online for non-emergency repairs. It is worth just calling that out. It has been great that we have been able to provide this to the residents.
We went through quite a lot of user research in the last beta round. We are up to around 40 different sessions now, across the live product. During that last phase, we have had some real successful feedback from it. With all the users we’ve tested our product with we were able to successfully log a repair.
I’m not going to jump into too much detail on these as I don’t want to steal Annie’s thunder later on. The summary of this is that users were able to flow through our process, understand the fields and the language that we have used in here. The language was a real focus of the user testing and has been continually updated and refined as we have gone through this.
It’s probably best at this point if I actually show you what the product looks like, now. Hopefully, that is coming through for everybody. This is the live Lincoln service. I am only going to be able to go so far with this, or somebody is going to get an operative turn up at their house.
This is the first landing page on here. As you can see, it looks very GDS-ey, as it was designed in the Gov.UK format. We just did the Lincoln branding around it. This first page is to try and make customers aware that there are types of repairs that this process doesn’t currently meet. This will be reduced as we come to the end of this next phase of beta. Leaseholder and communal repairs will be part of the journey moving forward. If it is an emergency, if they have a gas leak etc, we do still want the customer to call us where there is potential danger to life.
Coming through here, we’ve got our first triage point, just calling out if there is gas in here, if there is a type of emergency we provide those details for them. This works really well on those mobile phones, as from the data we have measured with the partners, over 70 percent of the customers were using mobile devices rather than a laptop.
Just for our process on here I am going to say it’s something else, that it’s not a communal area, and put in a valid property postcode. That does a live lookup behind the scenes, and only pulls back repairs that we do look after.
The customer can pick their address. This is where the real difference was between what we were developing, and a lot of what was on the market. Quite a lot of the products out there currently were based on a diagram of a house. It was a slight caricature, cartoon approach to things. People would say, “It’s my living room”, etc. What we found from the user testing is that not only was it not the most accessible approach, but quite often users were confused in that it did not look like their property. They lived in a bungalow, or it was showing a picture of a house, or the living room didn’t look like their living room.
We’ve moved to nice simple text in here that works well with screen readers. Then for every type of repair, we have got a three-triage system. First, the customer picks the room, then they pick the type of repair. I am going to go for something simple. Then there is the last point which is defining an SOR behind the scenes. What we did not do in here was display that complex language back to the customer.
I’m going to say that in my kitchen cupboard, I’ve got a problem with the door.
I hope that the customer puts in a much better description than this. They can also upload a photo at this point. Again, useful in terms of the diagnosis because it gives us the opportunity to see that repair, rather than over the telephone, somebody having to describe their problem.
Customers can find a number if somebody wants to get in touch. Something I should have called out at the beginning of this is that no login is required for this. Anybody can raise a repair on behalf of somebody. Granddaughters, grandsons, sheltered wardens, carers and so on. It just makes this a much more accessible product for everybody.
ANNIE: Yes, that answers a question in the chat, Fraser, about, “Is it mostly for citizens, or can it be used for field workers?”. It was designed so that –
FRASER: Yes, cheers Annie. I cannot see those comments coming through at the moment. Just to touch on that, of course, it does mean that estate officers and operatives themselves can use this as a tool. Primarily it was designed around the needs of the residents. We found that the number one blocker from doing the user research for using the existing service was the login. Removing that just makes this much more accessible to everybody.
It is also worth just shouting out because I know a lot of councils get concerned about rogue repairs being raised. Worthing had been running a similar process for a couple of years and had not had a single rogue repair raised. In the six months that Lincoln have been up and running, it is the same story there. I just do not think people have got that appetite at the moment to put their time into creating mickey mouse repairs.
This is now going off to the scheduling service at Lincoln and pulling back repair time slots that are applicable for that type of repair. You can see that some of these are quite far into the future. That is because Lincoln has just moved to a repairs-by-area approach. So, the customer gets to pick their date and time, get to know what is going to happen. If I click “continue”, that will log that repair, book in the operative and somebody will turn up to sort out their hanging door at that date and time.
One of the things that we’ve used is the open APIs into GovNotify. The customer gets an e-receipt and a record of what date and time has been booked. Moving forward, at the end of this phase, customers will be able to change that date and time in the future, and log leaseholder and communal repairs too.
Hopefully that has given a bit of a flavour of what this looks like, how some of this has been designed around those user needs. Hopefully, you can see it is nice and easy to use and see why all the customers that we have tested with were able to effectively log their repair.
ANNIE: I have got some questions.
FRASER: Okay, go for it.
ANNIE: I will be your questioneer. I will start with the smaller ones. “Are those appointment slots we just saw coming back from Lincoln’s housing management system?”.
FRASER: They are coming back from DRS, which is their scheduling software. It might also be known as Corona or One Advance, depending on how long you have been using the system.
ANNIE: Is there anything else you wanted to check or add, Jason, in your question?
JASON: No, I think that has answered it. Is anyone else live with this system that is bringing it back from a main housing management system? Because Corona is a mobile solution, isn’t it?
FRASER: Corona is a scheduling software. It does offer a mobile solution too; I think they call that Job Manager. Yes, in Lincoln’s case, it is just the scheduling element that we have purchased. We are just doing integration with Northgate’s NEC scheduling software at the moment. That is part of this next phase of beta. We are also investigating Total Mobile, which is another one of the leading scheduling software suppliers.
JASON: Okay, that is really interesting because we are NEC users at Hull, which is why I was asking. So certainly, of interest, there.
FRASER: Okay, great stuff, thanks Jason.
ANNIE: Alison would like to know, does the request integrate with the council’s back office and automatically raise a service request?
FRASER: Just to explain a little bit, there is a manual process in Lincoln. There are a couple of reasons for that. The integration with the scheduling software is live, and yes, it does create that job in real time so that an operative will attend. The appointment is effectively booked at the end of that user journey. The part that it does not do is log the repair in the housing management system at that point in time.
The reason for that was that we needed to pick based on the budget that we had got, which was the most effective approach for the user. That really was leaving them with that appointment date and time. It really reinforces that fact that we were building this around the user needs first.
We are looking at the integration into the housing management systems. With the version that Lincoln were running, specifically Universal, we did not have any APIs on there. Keeping in mind why we are doing this is for that greater good about reusability. We did not want to get distracted by an out of date, out of design housing management system. So, at the moment for them it just goes into the repairs scheduling system, but not the housing management system. That is manual.
ANNIE: Can a user go back and amend a repair once it has been submitted?
FRASER: Not today but that is part of that development process in this current phase of beta. They will be able to amend their SOR and date of time, or just cancel it altogether.
ANNIE: Then there is one that is about the number of users it was tested with. Was the total number fifteen?
FRASER: No, the total number was fifteen during the last beta round. We have had discovery, alpha, technical alpha, beta and then a second phase of beta. Throughout that we are well over fifty or sixty users now. It is around 34 in the beta phases. They have been from across those partners that you saw on screen earlier on.
ANNIE: Lovely. As well as the qualitative and moderated user research that we are going to have a look at in a minute, whether there were analytics that were gathered?
FRASER: There were, yes. How this was designed was based on the data that we had to hand. That was around the top SORs, or top types of repairs that were non-emergency. The product was built around that. We have also got the analytics in to understand things like the time of day that users are reporting these measures on here. It is really great that this is accessible 24/7 instead of the normal 9.00am to 5.00pm or whatever the normal contact centre hours.
Something we were really keen to build in were analytics on which promotion channel proves most effective for us. The thing I did not want to do was suddenly shout about a service across Facebook, putting it on the core weight queues, putting it in the tenancy signup packs, and us not understand which is the most effective channel. Again, thinking about other authorities taking this on board in the future, Lincoln is doing that in a staged process so that we can take that learning and other councils can rollout on the best channels for them.
ANNIE: Did you want to ask that follow up – I was going to say Nick, just assuming you were Nick Talbot?
NICK: Yes, it is Nick. More than fifteen, up to about 50-60 over the course of the project, great, thank you. In terms of analytics, I actually meant live analytics as you were testing, so you could see hesitations, miss-clicks, that kind of thing as they went through the form and flow?
FRASER: No, it was not that type of user testing.
ANNIE: Something like Hotjar?
FRASER: Yes. They did not do eye-tracking and things like that.
ANNIE: But in the sessions there are lots of notes about exactly that. The person hesitated here, or they looked there, but that is from watching rather than from a piece of kit.
NICK: Sure. In terms of – how did you define the sampling in terms of the users? I am working at Hounslow. We have about 14,000 tenants. We would like to do a lot more user research about this, but we believe there is a huge range of languages, different digital accessibility, different vulnerabilities, disabilities etc. How did you pick your sample sizes and your user types in each case, to account for these things?
FRASER: Sure. What I will put out there straightaway is that this is an NVP. It is not finished and it isn’t perfect yet. We did have some challenges during the user testing phase in that a little thing called Covid came along in the middle of this. We did have plans to go down and use the Empathy Lab at the GDS building, but that was closed off. What we did was reach out to the residents that were within the program already. Some at Camden and I think Hounslow were included in that to some extent, to get residents back so that we had a broad spread.
We also did incentives to try and encourage residents to step forward.
We didn’t approach the typical things like the tenants panel straightaway because by their very nature, they have a bias in them. We were trying to just get as broad a range as possible. Not all bases were covered but we did ensure that we approached as many different types of people as possible. We focused on the different types of residencies, things like the sheltered accommodation, those that we knew had carers alongside them etc, so we tried to get as good a breadth as we could.
ANNIE: A good thing you can do to not just go through residents associations is to try and work with the repairs team to either smooth out GDPR concerns around sharing information or ask that they contact people to say “Would you be interested in being part of testing for this repairs service?” to get that broader spread.
FRASER: I do just want to reiterate the point though that this is not yet finished. It will continually develop and that is why, as a project, we have always been looking for as many councils to get involved as possible, to help us understand the local challenges and needs.
I think people get into that mindset that this is a product off-the-shelf, and that it is finished. This is within the gift of local authorities to take its direction and to develop it around what we feel are those right areas.
NICK: Yes, I was just being a bit cheeky. We have obviously got a project going on at the moment. I was hoping for some quick answers to very difficult problems. Thanks for the responses and it is really great to learn from your experience as well, thank you.
ANNIE: We are more than happy to answer some more.
FRASER: If there are any questions that really are specific or you want to follow up outside of this, feel free to drop me an email and we can set some time up. Did you say it was Hounslow that you were from?
NICK: Yes, London Borough of Hounslow.
FRASER: I am talking with Franco over there already on this. If you wanted to loop in and park those conversations, I am more than happy to do so.
ANNIE: Alison wanted to ask, looking at back-office integration, are you looking to only API into Northgate or all solutions, particularly thinking about Idocs?
FRASER: For our first phase we are looking to use the rest of the API services that are in there because it is the most modern technology, and where it will be moving forward.
In terms of iDocs, I am not sure which element your authority is using. Obviously, they are a supplier that provides things like licensing document management. Within the housing management arena, I am not aware of how they fit into that.
ANNIE: Alison?
ALISON: Sorry, I was just struggling to find the Unmute button. Yes, it is the housing management module that they use, and various other modules tie into that licensing. Service requests as well. Hence my earlier question about whether this raises an automatic service request, if it APIs into that. I know that from an iDocs point of view, the modules are quite flexible as to where the APIs can feed into that. Yes, I was just interested to see where it was on your roadmap.
FRASER: Again, that roadmap is yet to be defined in some respects about what comes next, and what are those big needs. I think it is really useful to understand what would stop your authority taking this today. What we want to do is come up with that matrix to some level. To say if you’ve either got NEC or just Northgate IDocs and Total Mobile, Corona, whatever your scheduling software might be. We are working with these things to increase that spread of possibilities for authorities to adopt it.
We know behind the scenes the technical makeup is so complex but really, we need to get to the position where it works with any of those. There is an API layer that we have developed so that the principle of that is that it does not matter which of those systems, we just need to build in that logic. There might be that development that needs to be done for it to be iDocs, but I would not be concerned about it if there are APIs available to it.
ALISON: Right, thank you.
FRASER: No worries.
ANNIE: Any other follow ups?
FRASER: Brilliant, thank you for so many questions.
ANNIE: Hang on. Can you explain a bit more about what – oh, you mean weak signals when out and about on the estates?
ZAHIR: Hi, my name is Zahir, I work for Birmingham City Council. We are building a product at the moment for fieldworkers. Repairs is one aspect of something that we are building into the platform. One of the biggest areas of challenge that we have had is where the user loses connection partway through. They have started raising a repair and then they lose connection. How do you manage that and tackle that in this product?
FRASER: Selfishly, in Lincoln’s case it has not been an issue. It is such a small city that it was not something that has come up. It does not appear to have been one at Newark either. I think that because they are both district councils and so defined, although it is in Lincoln, the area is not rural that we are integrating with at the moment. It might be that becomes an issue in the future when we get to bringing this online with more tenants/residents, but at the moment that has not proved to be something that has caused us a problem at this point.
ANNIE: There is one more. Hang on, there are a couple. I must admit, I do not understand this question, Lynne.
FRASER: I have got that one Annie, yes. Connect to the SOR. At the end point of that triage system, so where I got to in that example of hanging door, behind the scenes we have got a mapping exercise to say that hanging door = this SOR code. Just to give a bit of background to this, when we looked at the top 50 SORs across Greenwich, Southwark, Lincoln and South Kesteven, we did our top 50 SORs and between all of those, there were only two codes that matched. That was between Lincoln and Southwark.
When we looked at the SOR description, we all had a leaky tap as one of our top fifty. Each authority was using a different one of the 2,000 subset or had created their own SOR to meet that. We had to accept at that point that it was going to be really difficult to come to a consensus on it. We allowed the authority to pick what they felt was the most appropriate SOR for that endpoint.
It really does help to drive down the understanding and measurements of what SORs are being reported. In Lincoln’s top fifty, I think we had five different tap ones, but that just depended on which customer service agent had chosen to pick which one. They get familiar with those. I know that is probably a long-winded answer but behind the scenes there is just a configuration file that mapped those endpoints. Hopefully that answers that.
LYNNE: I am not surprised by the solution, Fraser. You mentioned that there might be five different SORs that could be used for that repair. The trick is – the really difficult thing here is how you map that fault onto multiple SORs, isn’t it? Because the tenant is not providing enough information to do the fine tuning?
FRASER: The think is that from the customer’s perspective, what is important at this point in time is that we have got the right trade, with an appropriate amount of time.
LYNNE: Okay.
FRASER: If I think about if I had a problem at home with a tap, I would just ring a plumber and say, “I’ve got a problem with my tap.” He would come round and sort it. In the council world, we expect them to understand the finite details of the issue that they are faced with. I guess through this approach we are accepting that we are giving the customer some slack within the space. Putting perhaps a higher-level code on here and putting that onus on the operative when they go out to assign what was the correct SOR. Obviously, that should happen anyway as part of a process.
I think there is still a lot of work to do around that about an untapped data source or resource within this, that we could all learn a lot more from if we were doing diagnosis better. I think we have still got a way to go in terms of the measuring to understand what actually is happening around this.
One thing I would just like to call out is that there was a real advantage that the process wasn’t fully complete behind the scenes, because the CSA gets an email with the detail and with the photograph. So that if a tweak to an SOR is needed, hopefully it does not change the appointment time too much, they can still do that at that point.
LYNNE: Okay, thank you Fraser, that is helpful.
FRASER: Okay.
ANNIE: I have got one more, have you got it in you, Fraser? One more question.
FRASER: How does the system work in cases where emergency repairs are required? So, emergency repairs, it just doesn’t cater for at this moment in time. We want the customers to ring us because it could be that there is a risk to life or something of that nature. So, if they have got floods coming through the ceiling, if they’ve got a gas leak, if they are without electrical power in the midst of winter, we are just asking them to ring us. At this stage, we just signpost those out right at the beginning so they call us.
ANNIE: Splendid stuff. Okay, let us have a think about how user needs focus changes what we design and build.
The user researcher who worked on this project and I had a good chat about what we could show you, and exactly that – how the user needs changed and changed the design of what was happening.
We wanted to try and pull out an example that is a general good user research and user-centred design principle that could be used to anything that people are working on.
This is what we have picked. Firstly, to set the scene, here is the success criteria for housing repairs, and the actions that they would have to be able to do. With the subsequent slides, I am not going to go through each one, but it is worth having a minute to have a look at what these are.
A user is able to identify the problem from the options available to them and select the relevant radio buttons relating to the problem. If they are related to multiple problems, attempt to select more than one option.
Then there are two elements to this, the user is able to describe their problem to the council – textural, that they understand what to write in the description box and detail their problem – and visual, they are able to upload an image of their actual problem to the page. They know whether it has been uploaded correctly or not.
The user is able to book an appointment with the council, select an appointment time that suits and can clarify and explain that they know the appointment is booked.
What is interesting is that sometimes the parts that you think are the simple bits turn out to be what people are unsure about. The booking part you might assume would be straightforward. It turns out people weren’t sure whether the appointment was booked once they had done the booking step of the journey or whether they would have to hit the “complete” button at the end, or exactly when in the journey the appointment was booked.
You can see the stats about this on the next slide. This is round one of testing. Three out of eight users being able to identify their whole problem correctly is not too worrisome. These are the kind of tweaks you would expect around describing stuff, getting the room descriptions right, places, items, all that.
Nine out of nine could describe the problem, could understand what to write in the description box. They could do that textural stuff and the details of the problem, so that is absolutely fantastic.
Seven could upload the image, that is great. Only two understood they had uploaded the right one though. This is really helpful feedback to be able to dig into what needs changing. Appointments-wise though, some really interesting results that were a little more unexpected.
Five thought that their appointment was booked right after selecting an appointment slot. Three thought the appointment would be booked once the whole problem was reported at the end, and one was left still unsure whether it was booked at all.
If we move on to the next slide, here is a screenshot of round one of testing the process. The aim is not for you to be able to see the detail, just to see the process we went through of having each page laid out in order and then adding user comments. This is our whole journey, and each little screenshot is one page of the journey, and all the colours are the online sticky notes around them. This is really just to provide context for the next few slides.
Here are the screens. I will take you through some of the specific feedback as well. The booking an appointment screen, we had some useful feedback about the text on the page. There was too much text, and you could turn them into yes/no questions to guide them through. Where it says, “Before we visit, we need to know if any vulnerable people will be present at the property for the repair appointment, and any information on access restrictions. What we need to know includes…” This is where we can turn it into yes/no questions about if you have a medical condition, disability, or mobility difficulties, if you are a carer or are there any access restrictions.
That was really useful. There was just too much blurb and people were not really reading it.
Then the next one is the appointments. This is where they can choose what to select. There was really useful feedback here around needing to accommodate the school run. Actually, 12.00 – 4.00pm is more like, well, I can do 10.00 – 3.00pm every day but I cannot select that option because I am going to be out getting my kids. That was really, really useful. There was some around having first and second choices or about having more options. Some of the users thought they would be able to have more options than that.
The next screen, this is a selected appointment screen. At this point some people thought that their appointment was booked. For the contact details, this caused confusion with quite a few people because the main heading is “Contact Details”, which they have already given. It did not make it clear enough that it was specifically asking about how to confirm their appointment. The contact details you give might not be the way you would prefer to have that appointment confirmed, or to have someone contact you on the day about it.
People wanted to know why we were asking them again. As you put each screen together, this is making a whole journey that people are having to go through. You are trying to understand how all of these different elements might be making them confused about whether they have booked the appointment or not.
The next one, this is the Selected Appointment screen. At this point – sorry, this is the Report Summary. Again, some people thought at this point it was sorted, and if they stopped now their appointment would be – they would get their appointment and the person would turn up. So, we needed to make that clearer.
If we move onto the next one, these are the changes that we made in the subsequent rounds. You can see what the journey was in round one, and what the journey was in round two. You can see that in round one, the title of the first screen was “Booking an Appointment”. The third is “What is your phone number?”. We changed that to be clearer as to why we were asking for it and made it first. “What number should we call in order to get in touch?”.
In round two, we then asked how to confirm the appointment; by email, by text and so on. Then when you are available.
In round three we used the contact number given and populated the questions. As in, “Should we use 0712346222 to contact you?”
We turned five initial steps into three and changing the name of the report summary to Request Summary, that really helped as well. Then it feels like it is still in the request stage. Then, “Report Complete”. These changes made all the users confident that they had booked an appointment.
It is really interesting. You can simplify each section and you can work to gov.uk standards and GDS systems and make each individual page really clear and meet each user need. But sometimes you have to be able to test the flow of them all in the mind of the user and think about that whole journey to achieve what you want to. That is a really important part of user testing. It is a way that you don’t always necessarily expect user needs to affect how you build something.
We think about service design for the whole journey and for the whole thing we are building, but you have to think about the service design for the actual person using it, and what will make sense to them. The service design in their head of their journey, which is something that can be applied to be any build, it is not just housing specific. Really interesting. It is not just getting it right on each screen, it’s making that overall journey flow for everyone. That was a really interesting and useful thing that came out of building this, in terms of thinking about user needs and focus. There you go. Let me just open up questions again.
“Is there any guidance or training prompts as to how to take a good photo?” That is really interesting. “E.g., ‘Stand this close and make sure the light is on.’”. Did you find any issues, Fraser? I must admit, it is not something I have thought about a lot, I just thought people would be pointing and clicking at whatever their problem is. Is it something that you found in your initial discovery, Nick, is going to be something you need to think about?
FRASER: Was that a question for me, Annie?
ANNIE: I thought I would ask you both.
FRASER: Just answering from my bit, from the testing that we did, we did not find that to be an issue. I totally get that it is a valid point and something to consider.
I know something that we had thought about throughout this as a journey, was what were those self-help hints along the way? Part of that might even be the self-help resolution to some of these repairs, or about what might be the right time to connect them to somebody if it is a different type of repair. There is still quite a lot for us to think out and understand the best way to approach some of these things.
Just coming back to that as a specific question though, no, it did not come up as an issue but yes, totally understand the thinking behind why it might be good to include that.
ANNIE: Was it something that has caused you to think about it in discovery, Nick?
NICK: It is a concern in Hounslow but I would say the main evidence for it is that I used to work in Cape Town. A similar problem but slightly different. In the informal settlements, local residents or volunteers or employees of a charity would go around logging infrastructural faults like communal toilets, electrical services, water pumps and stuff like that.
Their model was purely mobile-based and very much photo-first, to say it that way. One of the problems they had was that they were using quite low-quality tech because it had to be readily available and easy to replace and in the field. It meant that the camera was already a bit lower quality. Secondly, in those cases because you had volunteers or employees, they found that the photos were not quite good enough for the repair side. They actually needed a form of training up front as to how to take a good photo.
Obviously, when you translate that to a council and it is tenants, these are volunteers or employees, so you do not get that small group of people that you are able to train up front. So, it is a combination of factors.
ANNIE: Yes, that is really interesting, what a different background that made you think about it. It has made me think about it. It is good that it’s an option in this context and not mandatory. There will be both those kinds of issues but also, digital-inclusion wise there will be people who do not have smartphones and can’t take a photo.
NICK: And a kind of alternative channel. I know that at Hounslow we have done a big drive to change our comms channels. Although we do not have a tonne of the new functionalities online yet, we are now starting to think about chat functions. In this case, what might be nice is say a video call. Again, not something super-common in councils between residents and councils, but the tech is there. Since lockdown, many more people are very aware of how to make video phone calls. Then you can kind of be walked through it, and it might provide additional detail beyond a photo. So yes, just food for thought really.
ANNIE: Yes, I completely agree. Like you say – I think there might have been a little lag there – especially now, when everyone is much more used to it, it is feeling more like that should be an option. Certainly, general advice would be to like you say, nail those comms channels down really clearly.
I started in housing in councils. I was the Website and social media Officer for Housing. One thing we noticed quite quickly was that there was a tenant and leaseholder Twitter account and Facebook account. Once people knew that there was a thing that was being regularly monitored and replied to, that started to be a shortcut if you had not heard back from your repairs. They would message me instead. It’s definitely a good piece of general advice to make sure that offer is clear and fair and there aren’t those kinds of delays causing people to try and work around the system.
It would be really good actually – it feels like the same kind of thing as these housing repairs which can be used by so many different councils – a little pilot around if anyone has already done video calls or if there is a few people who want to try that in councils, that would be a really interesting collaboration in the local government sector.
FRASER: The only thing I just want to raise on that is that it starts to particularly limit it back, in some cases, to office hours. Just to be mindful of those things. Without sounding like I am preaching, one of the other things that always bugged me working in local government was that kind of – I hate the phrase – silo thinking with things. It’s a much broader education piece of providing a good digital service across the board.
If you offer an awful council tax direct debit process where it’s all paper-based but then you’ve got a great Repairs Online service, whichever they interact with first sets the tone for how they are going to be interacting with you in future. My big challenge, back to Lincoln before I left, was that tenancy sign-up process.
It was 17 signatures we gathered, and gave out 24 paper booklets, and then we are surprised thatt customers call us when there are these things online. Surely, we could do something a bit cleverer around all of this.
ANNIE: Alison, yes, we are going to make the recordings available. I am really pleased you would like to share this with your housing team.
FRASER: There was a couple of questions before that as well, I think. One from Jess, working in reversal about what I would change if I had a time machine. I think it is not so much something that I would change but something I wish that had happened. That was for more authorities to get involved in it. There was that wider message and understanding of what those local issues are.
Sometimes it has felt a bit diluted in some respects by being similar sized authorities being the driving force behind it. Then people come to sessions or stand-ups and say, “Why doesn’t it do this?”. We do not know unless people get involved and we can understand and broaden that. I know that the biggest issue for all local authorities is time. That is our most precious commodity really, isn’t it? I know it is a big ask for people to get involved in this. I do just want to say that it does not mean that you have to adopt this as a product, just by being involved. It is about thinking well, what is that great product we can develop for as many users, residents, tenants, whatever you want to call them, that are out there. To get that best-of-breed out into the market and challenge the norm on this.
If somebody does want to get involved, we have got a next round of potential funding coming up. Newark is coming to the end. It would be great to have somebody else try and help the direction of this as well, and understand what those next stages are, and what should our roadmap look like.
I just want to come back to Zahir’s earlier one as well. It was not an app as such, but yes, we are on the fifth prototype. It has almost just been a normal web-based product. Yes, we are on that fifth round. Those five iterations have all occurred from that user testing.|
The biggest challenge, I think getting people involved. I would also say getting some of the housing management system providers to be interested and play a part in this.
By their nature, scheduling software suppliers sit in the middle. They are quite open in terms of sharing their documentation. They have been quite engaged with this, whereas housing management system providers tend to be quite guarded about the technologies. They do not necessarily want to share what capabilities they have of their APIs. That is changing, thankfully, but at the beginning of the project it was a bit of an uphill struggle.
ZAHIR: We are having similar problems in trying to integrate Northgate Housing, that is our biggest challenge at the moment. We have had similar problems there as well, that they are quite guarded. I was quite relieved to hear we are not the only ones who have had that challenge. It is a difficult one really because you want to be able to integrate into them, the applications to utilise their mechanisms for triaging the repair. That is a challenge that we have had in the past.
FRASER: I totally understand that. Just out of interest, Zahir, which authority are you from?
ZAHIR: Birmingham City Council.
FRASER: Okay, great. I have been in conversation with some people over there already but if there is anything we can do to help, we are just starting to do that integration testing. It might be worth us connecting after this.
ZAHIR: Yes, sure.
FRASER: Great stuff.
ANNIE: In general, and then I will get back to Alison, I just want to let people know that if you want to just talk general user-centred design, user-research, how to kick-start a bit of discovery or move to an alpha, just pick my brains on any kind of advice around user-centred design. It does not have to be housing. I’ve come from the same background; I get the problems and challenges that you experience. You do not always have huge multi-disciplinary teams or large budgets with which to do it. If anyone just wants to have a general chat and pick my brains in general, do feel free to get in touch.
FRASER: Am I all right to answer?
ANNIE: Yes, go for it.
FRASER: I think for that one it’s really that a lot of authorities don’t have something good in place at the moment and recognise that for those of us that do still retain our housing stock, it’s the number one reason generally that customers are calling us, for repairs. Failure demand is always through the roof. Again, our average across the partnership was 50 percent failure demand for the repairs. That was people checking their repair time, asking why somebody did not turn up or whatever it might be.
It was a clear win to be able to take something to an extent off the shelf, integrate it and start to deliver some value back to the customers. Again, wholly accepted that it doesn’t solve all the problems but it was catering to around 70 percent of the non-emergency repairs.
Even just shifting some of that demand away, about that 24/7 service, and just being part of something that it is within our gift to control its direction, I think for the authorities that have been involved, they want to challenge that space. Everybody recognised that what is out there at the moment is not all that great. Without naming any names.
Just in the last couple of minutes, I just want to say a genuine thank you to everybody for asking so many questions. It helps so much to have that kind of interactive session, and to understand some of those problems.
ALISON: Sorry, can I just tag onto the end of my last question there, about the business drivers? It sounds like it was from an organisational point of view, coming to yourselves because there wasn’t a robust solution in place already. Did you have any data to establish that tenants themselves had difficulty in logging complaints or felt they could not log complaints by going direct to the local authority?
Was it something that came from – obviously it makes it a lot easier for the tenant to log a complaint, we can see that. Was there any evidence that you had that tenants might have been worried to go directly to the housing agency or to their local authority? Because it looks very much like gov.uk styling, did they feel that they trusted that point of contact more so than going to the local authority?
FRASER: It is a good point to pick up on. I am guessing it was an assumption from our side, in that users are more familiar with that look and feel. I would not say there was any hard data on that. Again, from the user testing that we have done, the trust issue did not occur too much. By leaving them with that receipt that this is when somebody is going to be coming, they get that email or SMS at the end of this journey.
On a telephone call, they are reliant on writing that down themselves, so it gives them more confidence that it has been completed and that someone is coming at that date and time.
ALISON: Okay, thank you.
ANNIE: It is one o’clock. Zahir, I don’t know if you saw in the chat, but I led a project on fieldwork at Brighton. If you want to chat, I would be very happy to. If anyone else has any last-minute thoughts, now is the moment. If not, we have done that thing where we fill our allotted time. Excellent, thank you everyone. Like Fraser said, it is so much nicer, more useful, and more fun when everyone joins in, so we deeply appreciate that.
FRASER: Thank you everyone, bye.
Back to the episode
