ByStander
October 2022
Boyan Shao | Jiyoon Seok | Julia Correia | Mya Cipparrone | Yuqing Yang
ByStander is a futuristic technology-based medical health application designed to help users respond to sudden and unexpected situations in a timely manner. When the device is implanted in a person, ByStander can detect the user's health status and alert nearby people in case of an emergency. the ByStander app can automatically send messages to the patient's guardian or doctor so that they can provide timely help. In addition, the ByStander app can automatically generate rescue steps based on the patient's condition, making it possible for even ordinary people without medical knowledge to participate in the rescue. the ByStander project was completed in one month by a team of five interaction designers and represents their exploration and experimentation with future technologies.
PROJECT STATEMENT
Since our project cycle is only one month, we use Design Sprint This approach allows us to iterate on design solutions and find the best solution in a short period of time through a combination of teamwork, rapid prototyping, and user testing steps. This approach allowed us to produce a high-fidelity interactive prototype and conduct real user testing in a short cycle, which meant we were able to complete the design work efficiently and in a short period of time.
DEFINE & IDEATE
Topic BrainStorm
The purpose of this project is to explore potential future technologies and products. At the beginning of the project, we conducted a brainstorming activity to help us determine the project theme. Through researching future technology trends, each of us selected five topics of personal interest, such as "Two-Hour World Tour," "3D Printed Food," and "Transferring New Skills to the Brain," among other intriguing ideas.
Through voting and discussions, we chose the medical field theme of "Implantable Chips for Storing Medical Records." With this theme in mind, we engaged in divergent thinking and explored additional possibilities by combining other technologies.
What if this chip was more than just a storage device? What if it had monitoring capabilities like a familiar smartwatch? How could it provide assistance to its owner in case of an accident or emergency?
These thought-provoking questions allowed us to further explore the potential functionalities and applications of the chip beyond its initial concept as a medical data storage device.
HOW MIGHT WE
After we decided on the topic, we started the How Might We activity to generate various ideas. Everyone tried to come up with interesting ideas for medical records that are stored in our bodies, imagining a possible scenario in the future. Also, it was helpful for our group to decide on a great idea to develop further.
Based on our stickers, we can roughly summarize the problems we want to address into the following three categories:
-
Inability to communicate vital medical information to healthcare professionals during emergencies.
-
Disorganized healthcare record-sharing systems in Ontario, can lead to records getting lost and patients having to repeat important tests.
-
Medical conditions often being overlooked until they reach an advanced stage, making treatment more challenging.
These problem areas highlight the need for a solution that facilitates effective communication of medical information during emergencies, improves the efficiency and accuracy of healthcare record systems, and emphasizes early detection and intervention for medical conditions.
HILLS
The Hills activity further refined our problem space after establishing a general problem statement through the "How Might We" activity. The most significant contribution of this activity to our project's success was identifying the target audience.
While we knew the device could be implemented in anyone, it was unclear who would scan the device. This aspect was crucial and needed to be determined and agreed upon early on as it would greatly influence the direction of our solution.
Through brainstorming potential target audiences, products, and features, our team decided that the best solution would be focused on bystanders during emergency medical situations.
To carry out this activity, we set a 15-minute timer and individually brainstormed as many ideas as possible. Once we completed the divergent thinking phase, we discussed each idea as a group. We then moved our favorite ideas from each category under the chart and made slight modifications as needed. This grouping of sticky notes allowed us to visualize the entire concept more effectively. We continued discussing and swapping notes until we had two concepts that we were both eager to pursue.
Finally, we crafted Hills Statements based on these concepts and further discussed the pros and cons of each idea.
After our decision-making process, we chose the Hills Statement:
"Implant a device in a standardized location that detects the occurrence of emergencies. The device will contact emergency services and allow anyone with an electronic device to scan the implant."
Through the Hills activity, we were able to narrow down our focus, define our target audience, and establish a clear direction for our solution.
DESIGN STUDIO
At this stage, we got a clearer picture of the problem and started to envision the core features that the product might have. We each made storyboard sketches of key ideas. By visualizing and sharing the sketches, we better understood the ideas and found great similarities between each other. This helped us build a common idea and identify the necessary features needed for the product. This process led us to further refine our design ideas and ensure that the team had a common understanding of the overall direction of the product.
Our envisioned product includes the following features:
-
Automatic device notification without the need for scanning: The product can automatically send notifications to nearby devices without requiring manual scanning. This allows for faster attention from bystanders and prompt assistance.
-
Elimination of bystander effect: The product aims to eliminate the bystander effect by motivating nearby individuals to actively offer help. Through automatic alerts and clear steps, it encourages others to get involved and provide first aid or support.
-
Simple functionality and intuitive user interface: The product's features are designed to be simple and easy to understand, with a user interface that is intuitive and user-friendly. This enables ordinary individuals without medical expertise to quickly grasp and utilize the product.
-
Provision of specific emergency steps and communication with 911 personnel: The product provides specific step-by-step guidance based on the emergency situation and allows for communication with 911 personnel to seek further assistance. This facilitates real-time and tailored first-aid instructions, providing better support and aid to patients in emergency situations.
By incorporating these envisioned features, our product aims to empower individuals to respond effectively during emergencies, fostering a proactive and supportive community.
DEsign&PROTOTYPE
EXPERIENCE-BASED ROAD MAP
Up until this point in the project, we had many functions and concepts to include in our product but knew that not all of these ideas fit within the scope of our prototype, especially given the 2-week deadline. We decided to use the Experience-Based Roadmap in order to organize all of our ideas into different tiers, with the goal of getting the basic wants and needs of our product in order to deliver a prototype that was functional, without all of the wow factors that could wait to be implemented later.
For this activity, we began by noting down arbitrarily all of the different functions and aspects we would like to include in our product. Then, we organized them into the more important, short-term functions, and the less important but ‘would be nice’, long-term functions.
We then discussed more in-depth about each function, organizing them into the three tiers of “Cupcake” which would be our basic functionality, “Birthday Cake” (medium functionality), and “Wedding Cake” (all the bells and whistles). Our group was in general agreeance as to what should be included in the “Cupcake” model, but the “Birthday Cake” and “Wedding Cake” required more deliberation to specify what was more important, versus what would be convenient and ‘nice to have’.
The Main Capabilities of the product are as follows:
Proximity push notifications:
The product automatically sends notifications to nearby devices, alerting people in the vicinity about the emergency situation and the need for assistance.
Displaying important medical information:
The product showcases critical medical information about the individual in need, such as allergies, medical conditions, and emergency contact details. This information helps bystanders understand the situation better and provide appropriate help.
Guiding people on how to assist in the emergency:
The product provides clear and concise instructions to bystanders on how they can help the person in need. This can include CPR instructions, first aid techniques, or other necessary steps to be taken.
In addition to these core features, there are several other capabilities that should be included:
Stating the cause of the incident:
The product can provide relevant details about the cause or nature of the emergency to help bystanders better understand the situation.
Calling 911:
The product should have the capability to directly call emergency services, such as 911, to ensure that professional help is dispatched promptly.
Sounding an alarm:
The product can emit an audible alarm to attract immediate attention from nearby individuals and alert them to the emergency situation.
By encompassing these features, the product aims to facilitate quick response and aid during emergencies, empowering bystanders to provide effective assistance while ensuring the appropriate authorities are notified.
USER JOURNEY
Since we had previously determined what functions would be available for the “Birthday Cake” prototype, we used the functionalities available as a guideline for what the user would be able to do and see during the user journey situation.
We knew the journey would begin with the user receiving a notification of an emergency occurring, but had to decide on the order that they would see the next information. Since this would be used in emergencies, the most important information would need to be shown first — we discussed whether the emergency and victim information or the how-to-help information should be shown first, but decided that the user would need to know the details of the emergency before being able to help them.
Overall, the user journey starts with the user finding the victim having an emergency, scanning the device to receive information about the emergency occurring and about the victim, and then how to help them in that moment.
PROTOTYPE
After gathering input from all team members, we decided to use Figma to create our prototype. With a clear understanding of the tasks to be completed after the user journey, we have assigned each team member their respective sections and will discuss together if any modifications are needed upon completion. If there are any uncertainties or choices that cannot be confirmed during the process, we can utilize the commenting feature to leave a question that others can see and respond to.
Using the prototype, we will visualize the entire process of users receiving an emergency request and helping the patient according to the instructions. We believe it is crucial to ensure that users can quickly comprehend and respond to each step of the process.
The chip's functions include storing personal information and medical records, as well as issuing an alert when significant changes are detected in the owner's body.
ByStander is a mobile application that allows users to connect with the app after entering information from their personal chip.
When someone nearby experiences a medical emergency and requires assistance, people in the vicinity will receive an "Emergency Alert" message on their mobile phones. The message will display the patient's location and the suspected cause of the emergency.
Upon opening the app, users will be notified that 911 has been automatically informed and guided on how to locate the patient and scan their chip for detailed information.
Once the user scans the patient's chip by bringing their phone close to it as instructed, the phone will receive the patient's personal information, including emergency contacts, medical history, allergies, and more.
By clicking on the "How to Help" section, the user will be directed to a rescue guide page, which includes instructional videos and visual instructions in the form of images and text.
TEST & EVALUATE
USER TESTING
We conducted user testing with eight participants for the scenario where a patient experiences severe allergic symptoms, such as difficulty breathing and inability to move, while at school on the weekend. Once the chip detects the emergency, it emits an alarm sound and sends out a distress signal to users within a one-kilometer radius through ByStander.
Upon receiving the emergency notification in the adjacent classroom, the participants followed the alarm sound to locate the patient and then proceeded with the rescue steps as guided.
This user testing allowed us to gather feedback and insights on the effectiveness and usability of the system in a real-life scenario.
The primary goal of our testing was to determine if the user could quickly understand the information provided by the software in an emergency situation and quickly provide assistance to the patient. Our testing successfully accomplished this goal.
FEEDBACK GRID
After our user testing, we documented all the feedback we received on sticky notes. These notes were color-coded to represent different rounds of user testing. Duplicate notes were recorded in different colors to indicate similar feedback provided by multiple groups.
Once all the sticky notes were collected, we organized them as a group by creating a feedback grid. The feedback grid is a helpful tool that allowed us to visualize all the feedback we received. By mapping out the feedback, we were able to identify recurring issues in our design and prioritize the modifications needed for our prototype.
Next, we established connections between feedback ideas when taking action on one would address another. As a group, we determined which feedback was most important and beneficial for our next iteration. After reaching a consensus on the decisions, we began implementing the feedback through sketches.
In the feedback grid, we categorized the results of the user testing and participant feedback into four categories:
Worked Well:
-
Participants found the rescue steps to be simple and easy to understand.
Needs to change:
-
Some participants had difficulty scanning the patient's chip, indicating that the instructions may not have been clear enough in that section.
-
Textual instructions were found to be more efficient than video tutorials in emergency situations, as almost all participants skipped watching the tutorial videos.
-
Participants felt that the patient's personal information card added unnecessary reading time and suggested that displaying the rescue steps directly would be more suitable in emergency situations.
-
There was too much text that needed to be read.
Unanswered Questions:
-
Some participants were accustomed to swiping instead of tapping when receiving notifications. However, in emergency situations, the goal is for the emergency alert to be responded to immediately by tapping instead of swiping (swiping is used for old notifications).
New Ideas to Try:
-
The volume of the alarm was limited, making it difficult for users at a distance to hear. Adding a map feature to help locate the patient could be beneficial.
-
Minimizing unnecessary medical jargon to ensure that users can quickly access the necessary information and provide assistance.
FINAL PROTOTYPE
We made adjustments to the prototype according to the recurring feedback received, as follows:
First, it was clear that the scanning process was not intuitive; we modified our illustration of the patient’s device location to also include photographic imagery of someone using their phone to scan their device.
Second, since this product is meant to be used in an emergency, time is of the essence. We found that users were spending too much time reading all the text and patients’ personal information before helping them. To remedy this, we condensed a lot of unnecessary text and swapped the order of the pages, so that the How to Help page comes up immediately after scanning, wherein there is the option to see the victim’s personal info if needed.
Thirdly, although this is part of our “Wedding Cake” tier of functionality, a lot of users said it would be especially helpful to have location services to show where the patient is, so we added a directional map aid to do that.
When implementing these changes into the prototype, we divided the work between us, then re-tested the prototype to confirm its continuity was intact.
CONCLUSION
Bystander is a mobile application designed to empower individuals to respond effectively in emergency situations. The application utilizes a chip embedded in individuals' devices, which can store personal information and medical records. In the event of a nearby emergency, Bystander sends out an alert to users within a one-kilometer radius, providing crucial details about the incident and the victim.
The development of Bystander involved a comprehensive user-centered design process, including user research, prototyping, and testing. Through user testing, valuable feedback was collected to enhance the application's usability and effectiveness in emergency scenarios.
Bystander has been successful in achieving its goal of enabling users to quickly understand and respond to emergencies. The application's clear and intuitive assistance steps received positive feedback from users, ensuring that users can quickly grasp the necessary actions to provide help.
Based on user feedback, improvements were made to the scanning process, making it more intuitive and accessible to users. Additionally, the presentation of information was streamlined to prioritize the most critical details, ensuring that users can access the necessary information promptly.
Furthermore, the addition of a map feature in response to user suggestions enhanced the user experience by aiding users in locating the victim's position more effectively.
While the project had time limitations that prevented further iterations, the team remains committed to continuously collecting user feedback and implementing improvements in future iterations. Bystander has the potential to save lives and make a positive impact on communities by empowering individuals to act swiftly and effectively in emergency situations.
Overall, the user-centered design approach and iterative testing have been instrumental in refining Bystander and ensuring that it meets the needs and preferences of users in emergency scenarios. By prioritizing user feedback and ongoing improvement, Bystander aims to be a reliable and valuable tool for individuals to respond effectively and make a difference when it matters most.
More Projects
Here are more of my works.
