App for Centralised Shelter Occupancies in Real-time

Overview:

The Basecount mobile app is a tool that communicates occupancy information between shelter sites in real-time. I predominately contributed to product design and scoping of the mobile app, user flows, wireframes, lo- to hi-fidelity prototyping.

Challenge/Opportunity:

Basecount is a CivicTechTO project in the area of housing insecurity and homelessness in Toronto. Especially during the extremely frigid nights in Toronto, winter respite centres and shelters can literally be a matter of life and death for those who are unhoused or in precarious housing situations. Approximately 100 people experiencing homelessness die per year in Toronto. The problem this project focuses on is the lack of a central hub for communication between the key departments involved with shelters and temporary low-barrier sites that act like “pop-ups” when there’s an increased need, for example, when the City declares an Extreme Weather Alert (e.g., Winter Respite Sites). There is a high degree of inaccuracy of capacity and occupancy numbers being communicated amongst the departments, ultimately affecting how those most vulnerable experience. This was an issue identified from the Ombudsman Toronto Report, “Enquiry into City of Toronto Winter Respite Services 2017-18 Season”.

Imagine lugging all your belonging around the city only to be turned away—either you were told there were spots available; or there actually are spots, but they haven’t been able to keep track accurately and turned you away when there were indeed available spaces.

I definitely know I am privileged to have had absolutely no idea how the shelter system worked when I joined the project and was surprised at how complicated and inefficient things were with it. I found this image of the Toronto Winter Respite Ecosystem (created by one of the project members) below very helpful in just starting to wrap my head around it.

• 

Because there are several different parties involved in different parts/types of temporary shelter situation, it means that it’s imperative for them to have open and accurate information.

There are a few problems identified:

• no central location for occupancy and capacity numbers between the various parties
• different requirements and guidelines for intake between different types of shelter
• occupancy numbers are collected at different frequencies and intervals
• occupancy numbers are not enough information for temporary sites where capacity of the spaces can vary and change
• a lag in most-up-to-date info; no real-time information means having to try to predict occupancy

Solution:

I joined the team at the tail-end of the discovery and research phase so I joined in for the last session of the design sprint. Here based, on previously gathered research, interviews and relevant experiences, we explored all the different parts of the current set-up in terms of the involved systems, processes, responsibilities, people, logistics.

• 

• 

From the sprint exercises, we voted on the top two solution ideas and combined it to the solution we went ahead with: help streamline all the various communication issues amongst the numerous departments with a mobile app that will collect and share real-time data on site occupancy and capacity information so it is centralized, and easy-to-use. We chose a mobile app because most of those conducting headcounts for occupancy at respite sites are volunteers so it makes it a relatively more accessible option given that most people have mobile phones.

User Stories

For the mobile app, we identified four different user personas based on their role within a shelter/winter site. Each user has different needs from the app:

As a/an ____________ at a Winter Respite Centre…

…volunteer/junior staff member…

• I need to conduct up to several head counts per day
• I need to know whether we are at capacity
• I need to redirect people to another location if we are at capacity 
• I am very busy and don’t have time to learn or experiment 

…staff member…

• I need to report counts to SMIS
• (For some orgs) I need demographic info on clients (e.g., name, age, gender)

…shelter supervisor…

• I need to train volunteers/staff quickly
• I need to be able to give/revoke access to my volunteers/staff
• I need to create my shelter’s out of the cold schedule
• I need to represent what population(s) we serve at our shelter
• I need to represent what service(s) we provide at our shelter

…executive director/program manager…

• I need to have historical data for decision-making and reporting

Scoping the MVP

With various personas and wanting to get a MVP going, the next part was to scope what we want to include into Version 1. Based on the user stories, we use this to represent different Account Types which would translate to them having various different levels of permissions based on what data they should be able to access and what actions can be taken. I then translated this into the different features and what would be in our MVP and what would be later.

The core features are:

• Adding and editing shelter/respite sites
• Signing up/setting up user accounts – this depends on user type and affects permissions
• Viewing the status of any shelter or respite site
  • Seeing their recent/historical occupancy rates
• Ability for respite sites to update/change their capacity number
• Ability for users to input latest headcount numbers for their site(s), multiple times a day

• 

• 

• 

I then collaborated with the other designer to draw out user flows for each type of user, then the site map, and finally using that we moved it from lo-fi screens, styling, to a clickable hi-fi prototype build with Figma. Between each stage, we did some casual usability testing with fellow CivicTechTO participants and revised as needed.

User Flows

• 

• 

• 

• 

Sitemap

Evolution of wireframes & lo-fi, mid-fi, and hi-fi mockups

The UI aimed to be:

• clear, easy-to-use, and clean for volunteers or staff who may be less tech-savvy or just stressed from having a lot to deal with already
• darker colours to help with emitting less bright light when headcounts are conducted in the dark

• 

• 

Hi-fi Prototype

The prototype demonstrates various flows like:

• Login
• Settings
• Viewing/Adding/Editing Headcounts
• Configuring users and their settings (for Admins)
• Adding and configuring sites and their settings

Learnings:

• While we were designing, developers were starting to set things up on their end. It was challenging however to have enough developers to move as fast as we’d like.
• Related to the above, because this project was a group of volunteers, team members changed on a weekly basis. There was a core group, however, it was challenging to constantly onboard people, as well as have people not return and therefore can’t get their longer-term commitment.
• Lastly, it was most challenging throughout to communicate with the City and contact and talk to the appropriate stakeholders about our work and our solution.
• Ultimately by the time we were getting ready to code, the City had said they were already working on a solution internally and were not interested in seeing what we came up with or how we could share our work with them. It was a big blow to the morale and eventual dissolution to the project, but a key learning would be to really make sure there’s stakeholder buy-in and understanding the restrictions and barriers inherent (e.g., bureaucracy) before investing so much time and energy into getting so far. However, I learned so much professionally and personally from the multidisciplinary team and enjoyed all the collaboration!