Launching Arrival Advisor

Diverse newcomer personas

Based on interviews and research, I translated newcomers’ stories into a wide spectrum of personas, which were validated with frontline workers and newcomers. These were then used to co-create job stories which surfaced needs, painpoints, and goals across all these newcomer types.

The rationale for using so many personas at the start was to ensure that job stories/needs were surfaced through the diversity and not biased towards a singular type of newcomers.

Converging on who the product serves

Still, we needed to get grounded on who the product is designed for, and who it is not designed for, to move the product forward strategically.

Based on the personas, we prioritized which ones we could reasonably impact at the start.

I also facilitated an “identity wheel” exercise to make visible what factors put certain newcomers at the margins. As a team, we discussed and converged on what types of newcomers at the margins we wanted to be able to serve with our product. This informed who we recruit for research and what lived experiences are being engaged in co-design processes.

A spectrum of user contexts and situations

Beyond considering how a user’s identity shapes their needs, another method I used to surface “edge” user needs was by mapping out contexts and situations (temporal, geographic, social...) that could affect user’s ability to access settlement information.

Ideating the path for users to find and use information

The initial idea for Arrival Advisor was based on PeaceGeeks’ prior project, Services Advisor, a web app that maps where to find humanitarian services for immediately displaced refugees in Turkey, Jordan, and Iraq.

In our research however, not only did we find that there were already many existing service maps for newcomers to Canada, but these maps neglected an important problem. They assumed that newcomers knew what they were looking for. We created our information architecture based on the goal of helping newcomers first learn what they need, and then find the services to help them.

I then worked with my team to create flows, sketches, and wireframes, iterating throughout with newcomer and frontline worker feedback.

What information users need at each stage

A value proposition of our product was to deliver accurate information that is relevant and timely to the user's circumstance. To achieve this, we worked with newcomers and frontline workers to understand what resources newcomers need at different stages of their settlement journey.

Breaking down the content and creating the recommendation system

Then, we audited our partners’ information sources by how well they matched users’ needs and to which parts of the journey. I worked with my team to break down these information sources into small pieces, defining the content types, structure, and taxonomy of how the information would be used in the app.

To design the system for recommending information and services based on users' profile/preferences, we divided and sorted the topic and service data based on personas and user stories, informing the tags that we then created and applied on the topics and services to serve recommendations.

Personal without compromising privacy

Newcomers found the "recommended next steps" feature valuable; however, in interviewing asylum seekers and other newcomers who emigrated due to political persecution, many were hesitant to input personal, profile information in an app. They didn’t want to accidentally reveal any identifying information that would jeopardize their status.

To address this, we designed a way to offer newcomers default recommendations without filling the questionnaire. We also added other considerations to reassure users that their information stayed on their phone and wasn’t identifiable by us, such as the ability to use the app offline, no need to create an account, a "Clear all data" button, and the ability to skip questionnaire questions.

Tracking next steps without getting lost building a checklist

In an early design, users filled a questionnaire and received Recommended topics that they could add to their “Plan” (a checklist). On their Plan, users could then check off topics they completed.

When tested though, users were confused about the distinction between Recommended topics and topics on their Plan, and found adding to their Plan to be an extra step. Mixed task states (“Check off” a task already on your Plan, or “Add” if it is not on your Plan) felt complicated, especially for those less tech-savvy and less likely to task-plan digitally.

In response, rather than having the Plan as an isolated planning feature, I reorganized the experience to show users’ Recommended topics upfront, such that users could focus on seeing and completing their relevant next steps wherever they are in the app, rather than needing to learn how to keep track of next steps in a separate feature. Users could mark a topic as done wherever they are in the app. We also added a “Bookmark” feature for users to make a personal shortlist, as we found that Bookmarking was a more familiar interaction for less tech-savvy users.

Making it easier to find what you’re looking for

On the original topic detail page, where users would learn information about settling in Canada, we found that users had trouble noticing and using the button to “Find services”. In testing, users seemed lost and went into the related topics (at the bottom of the page) instead.

By reorganizing the content hierarchy in a redesign to help users better see the main content at hand, we found that users were much more successful at using the button to find services as well as consuming the main content without jumping immediately to related topics.

Creating a services feedback feature

We decided to create a way for users to indicate any services information that needed attention. In order to learn quickly on how to design this feature, I decided to build a quick prototype with a no code tool, such that I could rapidly test a solution using real service data.

Through this test, we learned to strike a fine balance on copy and placement of CTAs: welcoming users to submit suggestions (one interviewee told us that "Report an issue" felt too serious) without making users feel like the information was unreliable (another interviewee told us that if the button to "Suggest an edit" was too prominent, it implied that something was likely wrong with the information).