Lessons from the frontlines of service delivery

Team Jazz Casuals here, back with another dispatch from Toronto’s Shelter Support and Housing Administration. In case you’re in need of a refresher, we’re working closely with the division’s Policy, Operations and I&T teams to help implement Coordinated Access — a more integrated and consistent approach to assessing, prioritizing and connecting people experiencing homelessness to housing and supports. Implementing this system will involve changing many policies, business processes and operational procedures — and they all intersect with the application powering the division’s operations, the Shelter Management Information System (SMIS).

Every shelter in Toronto uses SMIS to manage their beds. The application allows staff to track bed vacancies and admit or refer clients to services where beds may be available. In order to deliver some of the key components of Coordinated Access and improve the experience for clients and staff along the way, the division will need to add new features and functionality to SMIS.

As with any project, there are a lot of things you could do, make or build, so how do you know what to build?

You are not your user

Whether you’re building an app or a clock radio toaster, just because your solution seems right and works for you, doesn’t mean it will make sense or work for other people (known as the False-Consensus Effect). To combat this bias and reduce the risk that users won’t like, need or be able to use what you create, it’s good to start by trying to understand your users and their needs better.

This means going to where your users are and observing them engage with your product or service in context. It means listening to the kind of language they use, noticing their behaviour, trying to understand their routines, habits and workflows. Do they use any other tools? Have they created any shortcuts? When do they get frustrated?

Since SMIS is an internal tool, City and shelter staff are our most direct users. They have to abide by certain rules and standards and follow certain protocols. The tools available to them shape their experiences and workflows.

The experience we’re focusing on is the first set of interactions a client has when they enter a shelter. Internally, this process is called ‘intake’ and it can set the stage for a client’s stay and any subsequent work they may do with shelter staff. One of the pillars of Coordinated Access is a more standardized approach to identifying client needs in the form of something called a Common Assessment, which is meant to facilitate more equitable resource allocation and match people to the supports that best meet their needs.

To better understand how staff get to know clients when they first enter a shelter and how the tools they use help or hinder the process, we had to get out of the office and hit the frontlines.

The goals of our research

• Get to know our users (shelter staff who use SMIS)
• Gain a better understanding of staff and client pain points, challenges and unmet needs
• Understand and document the intake experience, journey and processes

What we did

Criss-crossing across Toronto, we initially visited five different City and non-profit operated shelters and engaged with 23 staff. The primary methods we used were unstructured interviews and observation.

We spoke with frontline staff, shelter supervisors, client support workers and housing counsellors. Some were new to the work; others were 20+ year veterans in the field. They came from different backgrounds, had different levels of education and philosophies, but they all cared deeply about their work.

They showed us how they fill their paperwork — what goes where and when, what’s important and what they never bother to fill in. They clicked us through the screens and programs they use most frequently — SMIS, Word docs, spreadsheets, forms and other case management tools. We witnessed staff scramble to locate a translator for a refugee who arrived with mountains of documents. We observed as they rifled through printed logs (“Listed alphabetically now, finally!”), communicated with colleagues (“Anything to pass down from shift change?”) and continue working, unfazed, when something was thrown at a window (“We don’t say have a good shift, we say ‘stay safe’”).

It’s one thing to hear or read about “policy” and a whole other thing to witness it action. Policy, and things like technical specifications, often describe what should happen, but do not say how. That part has to be designed.

Key findings and how they’ve informed our work

As is often the case with research, users can help you discover things you weren’t necessarily looking for and point to areas of greater impact or more urgent priority.

Two inextricably linked takeaways have informed our work moving forward.

Valuable information is either not available or difficult to store and access

Shelters workers can see a client’s history in their particular program, but not much else. Having a better picture of a client’s history across the whole system would go a long way in preventing staff from repeatedly collecting information a client may have already shared — a major frustration for everyone.

Information such as the length of time someone has been homeless and whether they are considered ‘chronically homeless’ is not currently available but could be a valuable signal that helps supervisors and staff be more proactive in their outreach and engagement with clients. We know that if someone has been in shelter for six months, there is a much higher chance that they’ll become a longer-term occupant. After certain lengths of time, clients may also become eligible for more tailored programs or services. Without visual cues, it’s difficult to track and remember how long dozens of people have been staying in your shelter.

How might we surface more actionable data to inform client prioritization and engagement?

For our minimal viable product, we want to give staff the ability to see and sort their clientele by the length of time they’ve been at the shelter (number of nights they’ve occupied a bed) so that they can see — at a glance — who has been there the longest and take appropriate action.

Data permissions and sharing policy are too strict and inhibit continuity of care

Many of the pain points we discovered are actually the result of a feature, not a flaw. When SMIS was originally built, service providers were less comfortable sharing client information, so data-sharing across the shelter network was kept to a minimum. It is now apparent that the inability to see and share data between shelters and services leads to a frustrating experience and much more work.

For instance, there are a number of things people need in order to secure housing: a source of income, taxes and ID; social housing applications help too. Collectively, these are referred to as ‘housing essentials’. It’s difficult to search for and secure housing without them. The sooner staff know whether a client has these documents, the sooner they can assist the client and help them look for housing opportunities.

One of the biggest staff and client frustrations is that documents and information uploaded or entered at one shelter are not visible to staff at other shelters or programs.

We heard that clients regularly complain about being asked for the same information (“I already gave that at the last place”) and staff wish that key pieces of information like ‘housing essentials’ were visible across the system.

How might we share key information across shelters and programs to improve continuity of service and improve the client experience?

What this looks like is limited by some backend constraints, so we’re starting with the most simple technical solution. We’re advocating that a client’s assessment information — a form which contains their housing essentials and other information that can inform in-shelter support — be viewable at a new location if and when clients give consent.

Changing the division’s data sharing policy may not happen in our remaining months, but by raising frontline staff voices and surfacing these pain points we’re building momentum.

You can learn from the frontlines too!

You don’t have to be an anthropologist to do user research. Spending time with frontline staff observing and paying close attention to how they do their work can reveal plenty of ways a product, service, process or program can be improved.

The time we spent with frontline staff quickly clarified how we might improve their tools and help them help clients more effectively.

Whether you’re in the public, private or non-profit sector, frontline staff, like customer service or tech support representatives, are a direct line to your customers, clients or the people you serve. Look for where they get stuck and frustrated but also how they solve problems in unique or creative ways — it may inspire ideas for how to improve the experience for everyone.

Don’t forget, staff are your users too!

The Code for Canada fellowship embeds technology professionals into government, where they work alongside public servants to build great digital services. To learn more about becoming a fellow, or hosting a team of fellows in your department, visit codefor.ca/fellowship.