Travelert

Background

While we were looking for a topic for a group project in the Biomedical Engineering Ethics course, we found out that one member, an exchange student from Australia, hadn’t been receiving some of the emergency alert notifications the rest of us had gotten. Having previously lived in Japan where natural disasters are a common occurrence, I know all too well the importance of getting critical information in time.

Thus, we decided to look further into emergency alert systems around the world and how they worked. There are two main ways local authorities will send alerts: one method like cellular broadcast (CB) and SMS that depend on cellular networks and sends an alert to everyone within the range of the tower, and a second method that rely on websites and apps which make the information accessible from any wifi connection. The second remains a minority across the globe.

Problem statement and user profile

Through research, we identified two main barriers that users face when using existing solutions.

1. Not receiving an alert in the first place - Users without SIMs or a phone number will not receive CB based alerts.

2. Receiving alerts, but not understanding it due to language barriers - Even if they received alerts, it might be in a language they don’t understand.

Our user base includes anyone who will be travelling outside of their native country, and can be grouped based on the unique challenges they face: those not receiving CB alerts, those not understanding the language, or both.

This includes groups such as short-term and long-term travellers, exchange students, and immigrant families.

Individuals can fall into different groups depending on the particular travel details. For example, an American user travelling to the UK would only have the challenge of not receiving alerts, but they would additionally face a language barrier if they were to travel to France instead.

Empathy development plan

We conducted 5 interviews on individuals who are studying abroad, or have extensive travelling experience.

• Because the questions were around emergencies, that can elicit strong emotions when recalling events, or feeling embarrassment to admit not preparing for emergencies before travelling, we wanted to make sure that our interviewees felt that it was a safe space to talk about their experiences without judgement.

• We recognized that there’s a diversity of experiences that will differ based on the location and the context. So we wanted to respect the case-by-case basis nature, but also making sure it’s anonymized so that their privacy is protected.

• Additionally, we were mindful to use appropriate language when discussing residency, as being labeled as an immigrant family that can’t speak the language is a sensitive topic.

We also conducted a survey to capture the breadth of emergency alert experiences from 29 individuals who have travelled to foreign countries.

Because all members have experienced receiving alerts, as well as being in actual emergencies, we did not do extensive preparation to comprehend the user demographic’s perspective ahead of our interviews and surveys.

User/stakeholder needs

Out of the many user needs we gathered, here are some with the highest priorities:

• High priority: the ability to receive alerts in a timely manner, understand the language they were in, be able to review them at a later point in time

• Medium priority: prefer to have alerts in one platform

• Low priority: ability to adjust non-essential alerts, more information about where to go and what to do.

We defined high priority needs as factors that our solution MUST fulfill, and based our requirements off of this.
The medium and low priority needs are nice-to-have features that we wanted to add later on.

Requirements

Functional - the functional requirements will allow the new solution to be equivalent to existing cellular-based systems.

• Location change is required to allow relevant alerts to reach the correct people.

• The alerts must be received in a timely manner so that information can be acted upon accordingly. Delayed messages may become useless.

• Alerts should come from authorized organizations only to ensure they are not fake.

Inclusive - the inclusive requirements will help increase inclusivity of the design

• Alerts must be accessible to more people by using alternative communication networks (ie: not cellular)

• Decreases language barriers that are currently present by having more language options. 20 languages was chosen because this would cover about 80% of the world population.

• Alerts must be stored for at least 1 minute to allow users to re-read them in case they weren’t able to during the initial alert.

• The solution should be compatible with devices that can connect to WIFI because that is the next most common communication method aside from cellular.

Improvements - the requirements under the last category (improvements) are related to complaints from user feedback on current systems. 

• Users must be able to customize the alerts that are non-essential. For example, in some countries, weather alerts are broadcasted but may not be essential to immediate safety. Repetitive alerts like these can cause users to disregard or ignore emergency alerts which would place them in danger when more critical emergencies such as earthquakes or active shooters take place. 

• Information on the emergencies were sometimes insufficient because they did not provide information on where to go or actions to take. This indicates an area of improvement for the solution.

Initial concepts