Passport to Pittsburgh
Context
Passport to Pittsburgh is a visual aid and reference guide for Pittsburgh's international refugee population, created over a five months as a capstone project to complete my undergraduate degree at Carnegie Mellon's Human-Computer Interaction Institute.
As part of a six-person team, I worked with Jewish Family and Children's Services (JFCS), an organization that helps incoming international refugees acclimate to life in the United States, to design an intervention benefiting the organization's refugee clients. Our primary focus was JFCS's cultural orientation (CO) program, a structured 90-day period during which refugees were given instruction and training on topics ranging from English to Social Security to job-hunting. Our task was to identify gaps and needs felt by refugees within the process, and address them through a targeted design intervention.
As part of a six-person team, I worked with Jewish Family and Children's Services (JFCS), an organization that helps incoming international refugees acclimate to life in the United States, to design an intervention benefiting the organization's refugee clients. Our primary focus was JFCS's cultural orientation (CO) program, a structured 90-day period during which refugees were given instruction and training on topics ranging from English to Social Security to job-hunting. Our task was to identify gaps and needs felt by refugees within the process, and address them through a targeted design intervention.
Research
Key to designing a successful intervention was understanding how JFCS interacted with its refugee clients. In order to better understand the problem space, our team engaged with multiple different avenues of qualitative research, including shadowing classes, accompanying and interviewing refugees and case workers, and conducting a cultural probe to understand refugees' pain points within their own homes.
|
|
Synthesizing our findings revealed to us that transportation and planning were among some of the greatest pain points faced by new refugees; the cultural orientation process is one comprised primarily of appointments, and since most refugees were settled outside city limits, busing was usually their only way to reach these appointments. As such, the refugees' progress in the CO program was entirely contingent on their ability to use the bus. We heard multiple stories from JFCS case workers of refugees calling the office to ask to be driven to their appointments, because they didn't feel comfortable using the bus system. These conversations were revealing, as they demonstrated a problem area that was putting significant stress on both the refugees and the JFCS.
Although we felt we had isolated a problem for our solution to address, there were a number of key considerations and caveats learned through our research that any design solution we created would have to accommodate. First, the technological and societal know-how of the refugee population we were designing for varied dramatically from person to person. While certain refugees might have come from a technologically-savvy background, having owned smartphones or computers in their home country, others hailed from refugee camps with little to no exposure to these kinds of tools.
This meant that, if we wanted to create a solution that could be employed with all incoming refugees to the program, we would need to ensure that it wasn't reliant on technology that certain groups within our userbase would be unfamiliar with. This essentially meant that a software solution was off the table! Furthermore, the vast majority of refugees enrolled in the CO program arrived in the United States with little to no knowledge of English. As a result, many of the individuals for whom we would be designing were unfamiliar or uncomfortable with the bus system, and even if they had experience using public transit in their home countries, they lacked the English skills to read and plan using the city-provided bus schedules. As such, our solution would need to be primarily iconographic, and any text present would need to be minimal to ease the burden of translation later on.
Although we felt we had isolated a problem for our solution to address, there were a number of key considerations and caveats learned through our research that any design solution we created would have to accommodate. First, the technological and societal know-how of the refugee population we were designing for varied dramatically from person to person. While certain refugees might have come from a technologically-savvy background, having owned smartphones or computers in their home country, others hailed from refugee camps with little to no exposure to these kinds of tools.
This meant that, if we wanted to create a solution that could be employed with all incoming refugees to the program, we would need to ensure that it wasn't reliant on technology that certain groups within our userbase would be unfamiliar with. This essentially meant that a software solution was off the table! Furthermore, the vast majority of refugees enrolled in the CO program arrived in the United States with little to no knowledge of English. As a result, many of the individuals for whom we would be designing were unfamiliar or uncomfortable with the bus system, and even if they had experience using public transit in their home countries, they lacked the English skills to read and plan using the city-provided bus schedules. As such, our solution would need to be primarily iconographic, and any text present would need to be minimal to ease the burden of translation later on.
Design
Our primary goal with the transportation component of our design was to provide a way for our refugee users to:
1) know which bus they needed to ride to reach their desired destination,
2) find where to catch that bus,
3) identify and board the correct bus, and
4) get off at the correct location.
Because all of this would need to be accomplished with traditional materials (i.e., no electronics or software), we knew that our solution would initially only be able to provide guidance for a limited number of locations. Although we eventually designed a method by which JFCS case workers would be able to create guides for new locations, this was a constraint that we would have to contend with up to the end of the project. However, this constraint meant that we had to truly think critically about our users' journey through the CO program, and what locations they needed most help visiting. We eventually settled on a "hub and spoke" system focused on the specific locations refugees would need to attend as part of the program, like English class or the doctor's office. Users would leave their house, take a bus into downtown, and then take a bus from downtown to one of the subsidiary locations. This system meant that we could actually predict and plan for at least the first half of most trips that refugees would have to take in their first 90 days in the country.
1) know which bus they needed to ride to reach their desired destination,
2) find where to catch that bus,
3) identify and board the correct bus, and
4) get off at the correct location.
Because all of this would need to be accomplished with traditional materials (i.e., no electronics or software), we knew that our solution would initially only be able to provide guidance for a limited number of locations. Although we eventually designed a method by which JFCS case workers would be able to create guides for new locations, this was a constraint that we would have to contend with up to the end of the project. However, this constraint meant that we had to truly think critically about our users' journey through the CO program, and what locations they needed most help visiting. We eventually settled on a "hub and spoke" system focused on the specific locations refugees would need to attend as part of the program, like English class or the doctor's office. Users would leave their house, take a bus into downtown, and then take a bus from downtown to one of the subsidiary locations. This system meant that we could actually predict and plan for at least the first half of most trips that refugees would have to take in their first 90 days in the country.
With this system in place, we then began to design a series of "bus cards," which would be the primary design artifact for our transportation intervention. These cards would provide information with the intent of addressing the four key problems listed above, in an iconographic and text-light format. The bus card artifact went through a number of iterations, around the issues of return trips, visibility, walking distance, and other very low-level design considerations. Doing so provided the team the opportunity to step down from the abstract for a moment and think about the end-user experience in a concrete way.
|
|
|
|
Usability concerns like when users should signal the bus to stop, return trips, and walking directions were all key considerations that influenced the bus cards' design. Other navigational needs, like the location of the destination relative to the bus stop, ended up being relegated to separate location cards.
With regard to form factor, testing with our users in real-life contexts like bus riders brought us to the conclusion that our solution ought to be handheld. Furthermore, bodystorming tests hinted that our solution could pose as a more generic artifact for our users to carry around, like a wallet or a purse. With that in mind, we created the first recognizable iteration of the Passport: a small leather booklet containing our pre-designed bus cards and planning guides with a small enough form to be easily stowed and carried. Our intent was also for Passport to function as a wallet, holding users' cards, money, and so on. In this way, Passport would integrate cleanly into users' existing lives and workflows, and as a result would be considered essential, rather than extraneous.