Published: 2 Mar 2022 by Jemima Stevens

In the first part of her blog, Jemima shares some insights from a project conducted by Shelter’s digital team on how a triage system could improve user access to Shelter’s advice services. 

Once you’ve read part one, be sure to read part two next week

What was the problem?

Our helpline and webchat are very popular but oversubscribed services. In 2019, after running some trials, the helpline was repositioned as an emergency service to try and reach higher priority cases first. This was a positive change resulting in more urgent cases getting through to us. However, because of the housing emergency, demand for our services continued to surpass our resources.

As Lead Product Manager, Jane Kelly wrote in a previous blog that despite the changes to our helpline, data revealed that only 29% of incoming calls are ‘urgent’ or ’emergency’. Our current system has no way of identifying emergency vs. non-emergency calls which means that some of the people who are most at risk are not able to access our services.

Vision

We want to make sure people who access our advice services get the right support, through the right channel for their level of need, and can be escalated across our services seamlessly if they need further support.

What actions did we take?

For us to understand if we could achieve this vision, the team needed to uncover how users currently used our services and what issues they faced. This would help us identify how we could improve their advice journeys and get them to the correct channels for their need.

What is a discovery phase and how do we use it?

Discovery is the first phase in the design process of a digital product or service. Before you commit to building a service, you need to have an in-depth understanding of the problem it needs to solve. What you learn during discovery should help you work out whether you want to move forward to the alpha phase (the phase where something is built). The discovery phase aims to save time and money by only developing something that meets user needs.

For this project, we wanted to conduct a discovery to answer specific questions to help plan changes to our advice services. This involved speaking to working closely with people affected by the problem to better understand what they need, want, and would value from a solution.

How to start a discovery

Firstly, we asked ourselves lots of questions to break down any assumptions we had about the triaging process. During discovery, it’s important to avoid being solution focussed as we want our users to lead us to the answer.

Discovery goal

These questions led to creating a collective discovery goal so we would remain anchored to the problem throughout the project. 

“By completing this research, we will understand users’ needs, activities, environments, their use of technology and the constraints it imposes. 

This will provide an evidence_-based roadmap with defined next steps to inform and provide clarity on supporting the wider triage project vision; to have the capability to assess the urgency and complexity of user needs and transition users to a channel that will provide an empowering user experience.”_

How long did it take?

There’s no set time for a discovery; each will vary depending on the objectives and funding given.

We broke ours down into three phases which ran from April-August 2021.

Phase 1: Understanding Shelter, its services, and its current users

Understanding the current situation, landscape and technology used. Analyse research-to-date on Shelter’s users.

Phase 2: Engaging with users

Internal and external research with users and other stakeholders through qualitative and quantitative methods.

Phase 3: Analysing and giving recommendations

Evaluate options for improvement, form recommendations and create documentation.

Phase 1:  Understanding service offerings

In total, we interviewed ten team leaders and stakeholders from the Services Team and 11 internal advisors from webchat, helpline, social media, and hubs to get an understanding of what their services do and how their systems work.

We also wanted to know what challenges they currently faced and how the different channels connect. Using the information gathered, we created a series of service blueprints allowing us to visualise user journeys through advice channels and understand any pain points we should be addressing.

Phase 2:  Understanding the users

We analysed 15 helpline calls, 60 webchat transcripts, and seven social media conversations to create 82 micro personas. 

We then talked to 34 service users and narrowed down our personas to eight key personas who were observed the most across our sample.

We have since prioritised five final personas and drawn detailed profiles as well as ideal user journeys.

What is a user persona?

User personas help a product team find the answer to one of their most important questions: “Who are we designing for?”  

By understanding the expectations, concerns, and motivations of users, it’s possible to design a service or product that best supports their needs. A key part of a discovery project is determining these users and their personas, which can be used to inform final recommendations.

Here are some examples of persona titles:

• The Unsafe Soul – trying to escape an abusive partner
• The Checker – an inexperienced renter seeking clarification on rights
• The Aggrieved Checker- no trust in the supplied information
• The Loss Cutter – wants to renegotiate the rental offer to prevent eviction
• The Lost Soul- homeless after being thrown out of family home

Phase 3: Recommendations

The research and design work we carried out allowed us to put together a comprehensive report, explaining what we did, what we found, and our recommendations for how to implement a triage system. Find out about this in part two of this blog.

What did we learn?

This research was some of the first in-depth information we have gathered about our users and marks the start of a very important journey in understanding how we can make improvements to our service. The personas created are currently being discussed and validated to get them formally established across the Shelter Services directorate.

Our research highlighted that a triage solution should not focus on reducing demand or shielding users from using our services.

However, we can use a triage system to deal with demand more smartly so that those with the most severe housing needs can speak to an adviser immediately. Those with less urgent issues will have to wait a little longer to get their advice.

Internal and external user research showed no common understanding, adefinition of urgency or complexity within Shelter. This underpins the recommendation that a single set of priority levels needs to be agreed upon and defined across our advice channels.

This can then be used as a universal baseline of understanding to support the triage of users to the right channel. Defining, testing, and validating the priority levels will be the focus of the next phase. 

Research with service users showed they faced a range of barriers to accessing services. Many service users only have access to a smartphone, often with limited credit, and others only a landline. Our research also highlighted a large number of service users face physical or mental health issues and disabilities, making the accessibility of services a very high priority.

Summary

Using a discovery process allowed us to understand some of the key issues faced by users when they access our housing advice. It also showed us the intricacies of the channels and back-end systems that provide the advice, allowing us to identify opportunities to improve the experience for users.

By framing our research around the user needs we were able to focus only on building a system that would solve their access problems.

Collaboratively we discovered both a need and a clear opportunity to put in place a triage system that will help to effectively sort the incoming demand for services. To achieve this while meeting the needs of all service users, a series of recommendations has been laid out with a roadmap. Please read part two of this blog for more details