Design of the ‘request a repair’ feature for MTVH Online. 

Background

As landlord, our responsibilities include the repair and maintenance of our residents’ homes. Therefore, residents need to be able to tell us if there is a problem. Ever since the merger of Thames Valley Housing (TVH) and Metropolitan Housing (Met) 2 years ago, it is even more important that we deliver a consistent service to all our residents 

To provide services online, we have custom built web products that integrate with our housing databases. However, TVH and Met have different databases, and different online services 

To give all customers the same level of online service, we decided to build on and improve the existing TVH service, MyTVH. This new improved service will eventually be called MTVH Online, and will be individually integrated with the two legacy databases.  

This case study explains how we integrated the ability to request a repair in MTVH Online into the Met database (already integrated for TVH) and improved the process of being able to request a repair onlineI know, it’s confusing, here is a helpful diagram 

diagram to show the online services and the housing databases

Project main objectives 

  • To increase the quality of the data coming through by improving the existing ‘request a repair’ process.
    • The scope of the improvements was narrowed down to Request a repair only. The focus was on helping customers report a repair with enough information for colleagues to process it straight away rather than having to ask followup questions, and for the first appointment with a contractor to be successful. This meant leaving out things like appointment booking, rescheduling, automated status notifications and updates etc. 
  • MET residents to be able to request a repair online.  
  • The repair request to be integrated into the MET database. 
  • MET residents to be able to see the progress of their repair online. 

Constraints 

  • To improve the service, we must integrate separately the two housing databases. Therefore, we must build things twice, slightly differently. 
  • The databases are very restrictive in what we can build. 
  • The repairs can be carried out by many different contractors, each with different ways of doing things. This affects how we show the progress of the repair and other things in MTVH Online. 

What we did 

Discovery 

In order to improve the existing repair request process, we looked at the data and spoke with colleagues at the Housing and Property Desk to understand current limitations of the form, and what they needed to know in order to book a repair. This helped us find some of the basic problems: 

  • Residents often reported repairs that had already been reported.  
  • Colleagues reported insufficient information about what was broken. Residents therefore had to be called back to find out more information. 

Agile development

To deliver as much value to our residents as fast as we could, we needed a way for Met residents to report repairs online. To do this, we used an out of the box form builderOur earlier conversations with colleagues informed the format of the request form. Using this form, residents could now request a repair online. When sent, each request was given reference numberthat is emailed to customer services, who would then upload the request into the database, and schedule it for repair.  

Once residents started using this form, we could learn if our wording improvements had worked. Our minimum viable product (MVP) was up, and we continued to design and integrate the requests in an iterative, agile way. 

diagram showing flow of a repair inot the housing databases

Design 

The design principles that guided us when making design decisions:  

  • Design for simplicity. 
  • No jargon or confusing language. 
  • Use language consistently. Use the same words for the same thing!  
  • Give people one thing to do at a time. 
  • Mobile first approach 

I’ve broken down the design decisions we made page by page, rather than walking you through every iteration step-by-step.  

When booking a repair, we need to know where and what the problem is. The property desk can plan the type of operative needed – plumber or carpenter for example – what they need to bring and how long the appointment should beOur property desk colleagues said from the repairs requested online, they often had to call residents back to ask for more information. For example, there can be 10 bin stores on an estate, the operative needs to know exactly which one to go to, or for example in daylight you can’t tell which floodlight has gone out! 

Step 1: Space selection page 

First, the user must select what space is affected; is it a communal space or a personal space? From theiselection we can show a custom request form for that area.  

The space selection page was redesigned and simplified by:  

  • Categorising the spaces into ‘Personal’ and ‘Communal’ areas 
  • Using icons to make the options scannable.  
  • Reducing the text overall meant all the options can fit on one mobile screen. 
  • It’s important that emergency repairs are reported by phone. We added this to the first step of reporting a repair online. 
  • Updated the UI to match the new MTVH branding. 
  • Changed the options into radio buttons, with a ‘next’ button, rather than being a link that takes you to the next form. 

  before and after screenshots of the space selection page

Step 2: The Request Form  

The specific location of the repair was previously only indicated by a choice of 10 or so possible locations (radio buttons) for that space type. Consequently, customer services had to call residents back, due to a lack of detailThe radio buttons were replaced with a free text box. To help our users provide us with detailed information, we wrote custom question prompts for each space type. For example, the question ‘Where in your home is the problem?’, has the prompt is ‘ Eg. Wall opposite window in smallest bedroom.

before and after, form question asking for the location of the problem

We also added the ability for the space type ‘Room’ (rented by keyworkers or similar) to have an access request’ field. The resident can choose if they allow the repair operative to carry out the repair while they are not there.   

Communal repairs can be seen by any resident who has access to that space. We added some information at the top of the form, informing the user of who can see the request. 

Interaction 

We conducted usability testing on the new Met solution and the existing TVH solution to get the best out of both. The TVH form is one long form, while the new Met solution revealed 2-3 questions at a time. We found 

  • Users said felt more listened to’ when going step by step.  
  • Going step by step, users would try and refer to older questions, which had been hidden as they progressed through the form 

We decided to create a form that revealed one question at a time, but allowed the user to scroll back upto refer and check their earlier answers. The form was merged into one column, for better usability and accessibility on both desktop and mobile devices. This interaction was prototyped and tested, before being put into development.  

Step 3: Duplicate requests 

The final problem we had to solve was to reduce the number of duplicate repair requests being created. Duplicate requests get cancelled, so reporting them wastes the time of our customer services team who process them and the residents who report them. 

In the existing servicepotential duplicate repairs were linked to the location (remember those radio buttons?).  When the user selected a radio button, eg ‘bathroom’, all repairs already raised for the bathroom would appear under the title of ‘Related Outstanding Repairs. Research showed that this section was confusing to users. They assumed they could add more details about the repairs they were being shown, or these were related to what they were trying to do.  

screenshot of the old 'related repairs' in the form

To make this less confusing, sticking to our principle of ‘asking the user to decide one thing at a time’, we made checking for duplicate requests a new step, in-between the space selection page and the form. The user is shown a list of existing repairs for that space. They could either select one and add details or request a new repair. If there were no repairs already requested for that space, the user would go straight to the request form. The design of the repair block shown on this page was updated to also include the repair description, instead of when it was reported, making it easier to understand what that repair was about.

  screenshots of steps 1,2 and 3 together

Outcomes and lessons 

The Met temporary solution was replaced with this updated experience in December 2020. Met residents can now request a repair online, with the request going straight into the housing database, ready to be booked in for repair. Colleagues no longer have to upload requests manually, allowing them to work on more complex queries.  

Next steps: 

  • Look at repairs coming in, and investigate the: 
    • Cancellation rate of repairs reported online. Why are they being cancelled? Can we improve how repairs are requested so they are not cancelled? 
    • Number of follow up enquiries about a repair. How can we improve residents’ ability to track the progress of their request? In usability testing users said it “looks like office speak, and I don’t understand”. Reducing follow up enquiries further frees up the time customer services spend on them.  
  • Iterate on and improve the request a repair process: 
  • Can users choose appointment slots?  

 

 If you are a resident, register your interest to be part of the research, so we can continue to improve MTVH Online for all our residents.

Help us test our online services.

UX & UI Designer