Fall Detection System Table of Contents Introduction Application description Portfolio discussion User needs Next Steps Conclusion.......................................................... Portfolio Items and Reports Usability test design Report........................................... Portfolio item: Usability test design..................................... Mobile Application Security Report Portfolio Item: Mobile Application Security............................... HAZOP Analysis..................................................... Portfolio Item: HAZOP Analysis........................................ Wearable Mobile App Desktop Cognitive Walkthrough Report......................................... Portfolio item: Cognitive walkthrough................................... Appendices Appendix 1 High fidelity Mobile application prototype Appendix 2 Current applications in this domain Current relevant HCI research in the domain Bibliography

Introduction

The aim of this report is to demonstrate how our team shaped the second iteration of the design of our application interfaces. We designed four new portfolio items based on the first report. We achieved this by focusing on the usability of our design approach and by illustrating security features in addition to potential hazards. We based our approach on rigorous evaluation, as our application is a fall detection and health monitoring system for the elderly with multiple components that need to reliably work in emergency situations. The report focuses on discussing and providing reasoning for the four portfolio designs we generated as well as outlining the next steps we would take in developing the application. The sections “Current applications in this domain” and “Relevant HCI research in this domain” can be found in the appendix, as they were already included in the previous iteration.

Application description

Our application is aimed at providing functionality to wearable, smartphone and desktop platforms with the goal of responding to fall-related accidents among older adults in an efficient and timely manner, as well as, collect relevant medical information. The interaction between the different platforms is facilitated through Internet connection, as the wearable needs to send an event notification to the mobile app notifying the caregiver that there is a response needed. The caregiver then has the choice between attempting to contact the person in need, attend the accident themselves, contact the emergency services or perform all of these depending on the severity of the accident. The data collected through the use of our app on the wearable platform will also be compiled and send to a database that would be accessible by a doctor to monitor the development of the patient’s condition and would allow for pre-emptive treatment and measures to be taken before an injury or health deterioration occurs. Overall the app will aim to provide people at risk with a safety system that would ensure fast response when an accident occurs and would provide an array of information that can be used to assign better treatment and point out health issues before they become a real danger.

Portfolio discussion

The four portfolio items we designed focus on maximizing usability through usability testing and cognitive walkthroughs while keeping the application secure and analyzing potential hazards within a HAZOP analysis framework. The usability test and cognitive walkthrough both supplement the area of usability evaluation and aim to gather feedback on how to make the application interfaces as easy and reliable to use as possible.  In comparison to applications used in uncritical situations, any system used in emergency conditions where seconds count is required to be as reliable and easy-to-use as possible. This is the reason behind our choice to commit two portfolio items towards the improvement in these areas. The smart wristband as part of our application collects sensible information about its wearer, which is subsequently transmitted to the wearer’s GP doctor and to the mobile application in case of a detected fall. In addition, personal data needs to be accessed on the mobile application to provide it to EMT services in case of an emergency and to monitor a patient’s health status. As a large amount of sensible data is collected and saved, we aim to ensure a high level of security that still meets our usability criteria. Due to the critical importance of both usability and security for our application, our third portfolio item is the design of a security system, focusing on the mobile application. It aims to illustrate ways to restrict access to patient data on the mobile application and only provide it when needed in emergency situations. The challenge in this case is to provide the adequate level of security while still not hindering usability and allowing fast access. Our fourth new portfolio item is a HAZOP analysis. It aims to supplement all areas covered thus far by looking at the whole scope of devices and people involved within our application system. It identifies hazards and provides solution proposals. We decided on using this method to get an overview of hazards for the many different components involved in our application ecosystem. This supports the idea of creating an errorless and foolproof application that is reliable. Due to the use case of our application, we consider reliability of the components a key feature towards maximum usability.

User needs

Based on the new portfolio items some of the user needs have been updated. The older adult is concerned about personal safety in case of an emergency and wants to be assured that help is imminent at all times. The caregiver has many duties and cannot watch all older people at all times, but wants to be able to provide support whenever accidents happen. In addition, they need to access personal data to monitor patients health status. Hence they would need an easily accessible and reliable emergency response system that would maintain the integrity of the system without breaching security. The doctor wants to give best possible treatment to the older persons conditions, especially concerning pre-emptive treatments, e.g. for heart attacks, so he needs as much patient data as possible.

Next Steps

Fall detection is a complex and evolving process, where it is essential to provide rapid assistance and prevent adverse health consequences resulting from undetected falls. There has been an increase in the number of studies about vision-based systems, which show that their use in real-world scenarios have limitations (Igual, 2013). This is why we evaluated our system thoroughly in terms usability, security and potential hazards. Our next steps would be implement the portfolio items we designed and statistically validate the data through the use of questionnaires. To ensure accessibility, we would conduct one more iterative evaluation of our designed interfaces by involving visually impaired users, including those who suffer from dyslexia or visual stress. Based on their feedback, we would alter our interface designs. Subsequently, we would develop prototypes for all interfaces and set up a project plan for developing the application and its components in an agile approach. While developing the components, we would put emphasis on power consumption and privacy, as these will pose challenges regarding the performance of the system under real-life conditions.

Conclusion

The new portfolio items helped us gain a better understanding of how the different components can interact securely and how risks in safety critical systems affect the interaction design of our application user interfaces. Furthermore we identified core shortcomings in our design approach and how to overcome them through the addition of new features and rigorous testing.

Portfolio Items and Reports

 

Usability test design Report

Especially for the two interfaces of the wristband and the mobile application, usability is a key factor. As a faulty or difficult-to-use interface could potentially danger human health, an easy to use and bug-free UI is needed for the application to be reliable and actually helpful. Thus, usability in terms of HCI factors has to be tested rigorously. An approved method for effective usability tests is the use of a usability lab. This method can be considered an experiment on how to improve our applications interfaces based on feedback on user performance. This portfolio item focuses on designing a usability test for the two critical application components of the mobile app and smart wristband with the tools a usability lab offers. The usability test is used to test the design and functionalities developed in their current state and to subsequently derive improvements to the components interfaces from the tester’s feedback. The reason why this method was chosen is that it bears numerous advantages over other forms of generating user feedback: Firstly, a usability test identifies problems that will plague the actual users of the application effectively due to the “hands-on” approach. (Jeffries & Desurvire, 1992)  This especially applies for testing the haptic interface of our wearable, which would be difficult to simulate with remote testing or questionnaires. Secondly, the high quality of the feedback generated helps minimise the risk of the finished product failing to perform according to expectations by uncovering design flaws not accounted for by the designers and developers. (Usability.gov, 2018) Due to the use of our application in emergency situations, ensuring errorless functionality is critical for its success. Thirdly, due to the environment of a usability lab, the highest possible number of KPI’s can be measured, again providing insights other methods might not be able to. However, testing with usability labs also bears disadvantages, most importantly the high effort required to set up the test environment and the high costs to pay for the use of a usability lab and to compensate test participants. Compared to that, remote/online usability testing and questionnaires only require fractions of the effort and costs. Another disadvantage is the qualitative nature of the generated feedback, as compared to questionnaires or remote testing only small samples can be generated, which may not be valid from a statistical point of view. For the use in our application we consider a usability test as highly useful, due to the mentioned advantages. However, for validation the results should be complemented with large data samples gained through questionnaires or other forms of feedback generation. The expected outcome of the usability testing process is primarily to get evidence that the interfaces of the mobile app and wearable work reliably, as intended and without errors, and secondarily to gain insights on areas of improvement for the interfaces in different scenario situations, e.g. whether or not the countdown length of the wearable alarm trigger is suitable.          

Portfolio item: Usability test design

The application our group is designing has three different interfaces. Elderly adults/patients engage with the application through a wearable wristband with a large button that can be used for two purposes:  to trigger an emergency alarm and to stop an automatic emergency detection if there is no actual emergency. See the picture below for an approximate view of how the wristband could look like. The wristband has various sensors installed, with the purpose of monitoring the wearer’s health data and location. In addition, a sim card is included to establish a cell connection between the wearer and a caregiver monitoring the mobile app in case of an emergency. The second interface is a mobile application, designed for caregivers to monitor if the wristband sends an emergency alert. In case of an emergency, the caregiver can initiate contact to the person wearing the wristband and, if necessary, call an EMT service to the transmitted accident location. Additionally, relevant health data recorded by the wristbands sensors can be transmitted. The third interface is a desktop application, designed for medical doctors to analyze the health data a wristband transmits to adapt medical treatments for their patients. The purpose of the test is to generate feedback for the following question: Are the applications interfaces suitable and errorless to allow users to execute critical application features in an efficient manner while under the stress of an emergency situation that potentially affects human health? Deduced from this, the most important KPI’s we want to measure are part of the quantitative performance measures first defined by Wixon and Wilson in 1997 (Wixon & Wilson, 1997) adapted to fit to the circumstances of our user interfaces:

• Time to complete a task
• Number and type of errors per task
• Number of errors per unit of time
• Number of users making a particular error
• Number of users completing a task successfully

To gain a statistically acceptable range of feedback, 5 test groups consisting of caregiver/patient pairs should be used. The participants should, if possible, resemble typical users, meaning actual caregivers and elderly persons. Before taking part, each participant should read and sign an informed consent form agreeing to terms and conditions of the usability test. The form should describe details of the test procedure, approximate length, compensation, information about the right to withdraw at any time, a promise of guaranteed anonymity of personal details and that the data collected is treated confidentially and not be made available to anyone other than the evaluators. The gathered test results should be complemented with a questionnaire filled out by the participants after test completion to evaluate the perceived effectiveness of test methods and feedback on room for improvement of the usability test design and layout. To conduct a usability test for all three components with their respective users, it is planned to use a controlled and monitored environment in the form of a usability lab with the following design specifications. The usability lab should be equipped with technology to monitor user activity and interaction with our interfaces, specifically with video cameras and microphones recording all scenarios, screen-tap and eye-movement logging for the mobile application and mirrored window for members of the project team to watch the test without distracting the participants. In addition, a soft gym mat or a similar object on which it is safe to fall for humans should be provided for the participant testing the fall-detection of the wearable interface and its reliability. The following scenarios should be tested in the usability lab: Firstly, the scenario of a patient falling and the wristband recognizing this and starting a countdown after which an alarm would be sent to the mobile app monitored by a caregiver. However, the patient is able to help themselves and does not need further support, so they cancel the alarm. Secondly, a scenario similar to the first one, with the difference that the patient does not cancel the alarm countdown this time, due to being unconscious or acknowledging they need help. As a result, the wristband establishes voice communication to the mobile app, allowing the caregiver to speak to the patient and see relevant health data to assess whether an ambulance is needed or not. In this scenario, it is assumed that an ambulance would be needed, so the caregiver subsequently initiates contact to EMT services, providing them with all relevant information via phone. Thirdly, a scenario where an alarm is triggered by the wristwatch and communication established with the caregiver. This time however, the patient is able to help themselves out of the situation by following instructions given by the caregiver through the established phone connection.

Mobile Application Security Report

Throughout history usability and security have always been considered as trade offs when designing any user centered system. UX designers had specific job requirements to design and implement human computer interaction systems that favored usability while the security expert is brought on in later stages to make systems more secure. However, with advancements in both HCI systems and security attacks the two job requirements have merged.  The system must be secure enough to protect the user’s data but not too secure that the user cannot access the system. The system we aim to design will need to have a very high usability standard since it is an emergency response system and time is of the essence when accessing the mobile application. However the wearable device will be collecting data about the patient at all times and the system will have to be secure enough to keep the patient’s data private and only accessible to the appropriate user. Hence, we chose to dedicate this portfolio item to security. We revisited the mobile application prototype (Appendix 1) to evaluate it and improve the design by applying techniques that were found in various academic sources. Kobie (2016) argues that the relationship between the two components does not have to be a trade off. He quotes Justin Hevey “Security needs to be embedded into sprints in planning, design and implementation phases,” The approach that helps bridge the gap between the two concepts while maintaining the integrity of the system is called Security by Design, which is “…the premise that security should be built in earlier in the development process, rather than awkwardly tacked on at the end” (Kobie, 2016).  Therefore the security expert of any project should be involved in every stage to ensure that there are no attack vectors in the system. Furnell (2016) also believes that today’s technology has evolved enough for the two components to coexist without damaging the integrity of any system. He explains how “devices have advanced [...] through the use of biometrics, with significant examples including the arrival of face unlock on Android and Touch ID on iOS devices… they have made security easier and more friendly and thus increased the chances of it getting used.” Thus, we decided on using the Security by Design and biometric authentication for our system. We expect that the ratio between usability and security will be balanced. Therefore the users will be able to use the mobile application without any inconvenience while keeping the patient’s data secure.  

Portfolio Item: Mobile Application Security

Through the mobile application the caregiver can access two main components of the Fall Detection system. The first one is the emergency response component which allows the caregiver to respond in case of a fall being detected. The second one is the data analysis component, a section where the caregiver can monitor the patient’s medical status at any point in time. The most important feature of our system is the emergency response mechanism; hence we came to the conclusion that the security of the system should not hinder the user while responding to any kind of emergency. In an event of a fall being detected by the wearable device, an alert is triggered; we will have minimal but reliable security on the mobile application. If the caregiver is using a mobile phone with biometric accessibility, for example fingerprint scan or facial recognition the system will allow the user to use a biometric authentication to respond. For example the caregiver responding to the alert would be able to scan their fingerprint and quickly access the mobile application to respond. The sequence of events would go as follows:

1. Fall alert is triggered
2. Receive notification from the mobile application
3. Access the application
4. Scan fingerprint
5. Access the system to respond appropriately

However if the caregiver has a mobile phone with no biometric capabilities then password protection would be necessary, and the sequence of events would change to:

1. Fall alert is triggered
2. Receive notification from the mobile application
3. Access the application
4. Enter password
5. Access the system to respond appropriately

In an event where the immediate caregiver would need to access the patient’s data to monitor their medical status at any given time the system would require an extra security layer. Once the caregiver is navigating through the application and he/she wants to access the data section, they would need to provide a password for full access.

HAZOP Analysis

In a system such as ours, which deals with potentially life-threatening circumstances, performing a risk analysis is crucial for a thorough design evaluation process. As expected it provided us with many ideas on how to improve our system and what features need to be added to improve usability and security. Thus, we performed a HAZOP risk analysis on our user interface design for each platform. There are various methods to conduct a risk-assessment evaluation. Hazard Analysis was considered too broad and general for our purposes with its top-down approach (Hussey and Atchison, 2000). PHEA was attractive at first as it would focus on the mistakes of the users of our system and would allow us to consider the different steps in the HTA analysis that we presented in our previous report and the possible mistakes that the users could make while interacting with our system. Eventually we decided to adopt the HAZOP method as a middle ground between the user-centric PHEA and the top-down nature of Hazard Analysis. HAZOP provided us with the whole spectrum of possible risks that our system can face and proved to be especially helpful in developing new features. By adopting a systemic examination of risks and tasks in the form of HAZOP, we expect to identify weak points in our system and put in steps to alleviate the dangers of these occurrences taking place. We used the collective brainstorming intended by HAZOP to develop scenarios with the help of a great variety of keywords at first which were later narrowed down to six. The standard version of HAZOP was used because we did not look at risks that can develop simultaneously to test the safeguard developed through the analysis or added graphical representation of risks’ likelihood (Herrera et al, 2015). For the purpose of this assignment we are going to leave out some of the later steps of HAZOP where risks are given a time-frame to be addressed (PQRI, 2015). The discovery of deviations allowed us to gain a better understanding of the issues that can surround our system and made us aware of many of the possible risks that our application can be subjected to due to a fault in the equipment, incorrect use of the system and factors outside the interaction between it and the user. Our study is separated into 3 sections based on the part of our system. This means that there is a separate table for the wearable user-side of the system, one for the mobile app and one for the desktop version used by the doctor. One drawback of the HAZOP analysis is that it looks at risk events individually rather than at a combination of them, which can limit the predictability of more complex issues. In addition, HAZOP does not deal with quantitative data as it determines the heuristics of the possible events that can lead to hazardous situations (Baybutt, 2015). In later stages, when we have more detailed prototypes, collating statistical data points from experiments can provide us with more practical data as to what to expect when the system goes live.

Portfolio Item: HAZOP Analysis

Key words: Incorrect, Undelivered, No, False, Overflow, slow

Wearable

Item	Guide Word	Deviation	Causes	Safeguards	Consequences	Actions
1	Communication	No Communication;	No battery charge; Network not available; Device malfunction;	Sound notification for low battery; Sound notification for no network connection; None	Potential death from untreated injury; Potential death from untreated injury; Potential death from untreated injury;	Message reminders to charge at regular intervals; Carry out regular maintenance; Provide a network coverage map; Provide training for avoiding locations with low network coverage; Monitor device connection to network and provide notifications if the connection is unstable Pre-program a message advising caution and maintenance when an issue is detected;
2	Communication	False Communication	Software bug; Unintended pressing of the assistance button	None None	Unneeded assistance; Battery drain; Incorrect patient data; Unneeded assistance; Battery drain; Incorrect patient data;	Setting up a system of attempted mobile phone contact to confirm a request is genuine; Making the manual request of assistance a two step-process;
3	Charge	No Charge	Faulty Battery The battery not being charged;	None Sound notification for low battery;	Potential death from untreated injury; Potential death from untreated injury;	Regular testing of devices; Message reminders to charge at regular intervals;
4	Charging	Slow Charging	Battery fatigue; Issue with the device charging port; Issue with the charger;	Sound notification for maintenance required; None; None;	Inability to use the device; Inability to charge the device; Inability to charge the device;	Perform a check as part of the regular maintenance; Make the battery easily replaceable; Make the part easily replaceable by a technician; Use standard issue USB chargers;
5	Detection	False Detection	Issue with the accelerometer; Software bug;	Sound notification for maintenance required; None;	Unneeded assistance call; Battery drain; Incorrect patient data; Unneeded assistance response; Battery drain; Incorrect patient data;	Setting up a system of attempted mobile phone contact to confirm a request is genuine; Review collected data to identify issues regularly;
6	Detection	No Detection	Issue with the accelerometer; Software bug;	Sound notification for maintenance required; None;	Potential death from untreated injury; Potential death from untreated injury;	Perform a check as part of the regular maintenance Review collected data to identify issues regularly;
7	Response	No Response	Caregiver unavailable; Detection not escalated to emergency services; Communication failure;	Escalation to emergency services system; Admin notification; Retry Process;	Potential death from untreated injury; Potential death from untreated injury; Potential death from untreated injury;	Ensure the escalation to emergency services works; Admin calls the emergency services; Provide a network coverage map; Provide training for avoiding locations with low network coverage; Monitor device connection to network and provide notifications if the connection is unstable;
8	Response	Slow Response	Delay in answering the notification by the caregiver; Bad network;	Refer to a different caregiver or emergency services Retry Process;	Potential death from untreated injury; Potential death from untreated injury;	Develop an escalation list that includes other caregivers and ends with Emergency Services; Provide a network coverage map; Provide training for avoiding locations with low network coverage; Monitor device connection to network and provide notifications if the connection is unstable;
9	Control	No Control	Assistance Button Malfunction;	Voice control option;	Inability to request for assistance manually in certain situations;	Carry out scheduled maintenance checks;
10	Sound	No Sound	In-built speaker malfunctions	A visual notification in the form of a blinking light;	Important sound notifications might be missed;	Introduce haptic notification;
11	Casing Integrity	No Casing Integrity	A crack in the outer shell of the device; A strap comes off	Durable plastic casing; Durable rubber straps	Possible malfunction of the assistance button; Possible malfunction of the whole device; Possibility to make the device unusable;	Use soft rubber coating in the bottom layers to prevent water from seeping in Provide temporary spare straps;
12	Body Presence	No Body Presence	The device has come off the user’s wrist; The user has forgotten to put the device on	Secure fitting of the device; Training manual with suggested morning routine;	The user’s condition is no longer being monitored; The user’s condition is no longer being monitored;	Provide secondary strap to ensure the device is not lost if the main fitting does not keep it in place; Provide an auditory reminder to put the wearable on
13	Body Presence	Incorrect Body Presence	The device is situated to high on the arm The device is attached too loosely to the arm	Instruction manual and demonstration available at first fitting; Instruction manual and demonstration at first fitting;	The accelerometer does not provide accurate data; The accelerometer does not provide accurate data;	Monitor the device’ feedback for the first week and provide advice for the user on proper use of the equipment; Monitor the device’ feedback for the first week and provide advice for the user on proper use of the equipment;

Mobile App

Item	Guide Word	Deviation	Causes	Safeguards	Consequences	Actions
1	Notification	No Notification	Mobile Phone switched to silent and no vibration; Mobile phone switched off;	None; None;	Caregiver will not be aware of the alert Caregiver will not be aware of the alert	Suggest to the organisation using our system to provide work phones with no possibility to switch off the sound and vibration notification; Suggest to the organisation using our device to provide work phones with continuous feedback to a system which will notify when a phone goes offline;
2	Notification	False Notification	Caregiver receives a false automated assistance notification;	None	Caregiver might lose important time during which he could have helped someone else;	Caregiver waits to receive a phone call, presence on body confirmation
3	Overflow	Overflow of Communication;	Caregiver receives too many notifications	Automated distributions of tasks;	Caregiver could be overworked and not be able to respond to all assistance calls;	Create an admin user who will overlook the systems’ responses and intervene when necessary
4	Presence on Body	No Presence on Body	Caregiver leaves the phone somewhere;	None;	Caregiver will not be aware of the alert;	Ensure the organisation using our system provide the necessary training;
5	Information;	No Information;	Caregiver forgets his personalised password needed to access a patient’s health data	Password reset process;	Caregiver might not be able to access important information regarding the patient’s health;	Create a backup process that allows the data to be communicated to the caregiver over a phone conversation;
6	Communication	False Communication	Caregiver receives a false communication	None;	Caregiver might lose important time during which he could have helped someone else;	Caregiver waits to receive a phone call, presence on body confirmation;
7	Communication	Overflow of Communication;	Caregiver receives too many notifications	Automated distributions of tasks;	Caregiver could be overworked and not be able to respond to all assistance calls;	Create a position of admin who will overlook the systems’ responses and intervene when n necessary

Desktop

Item	Guide Word	Deviation	Causes	Safeguards	Consequences	Actions
1	Recommendation	Undelivered Recommendations	Disconnected from the network User’s mistake;	Backup all recommendation locally and on the cloud; Easily navigable website;	Recommendations will not reach the caregiver and patient; Recommendations will not reach the caregiver and patient;	Display a notification offering different methods to connect;
2	Information	Incorrect Information	Database incorrectly set up User’s mistake	Database backups Easily navigable menu with hints and good and effective search engine;	Doctors would not be able to find and update the patients’ information	Cross reference with another system Provide backups

Cognitive Walkthrough Report

The cognitive walkthrough is a usability evaluation method that requires one or more evaluators performing a series of tasks and asking several sets of questions from the users perspective (Wharton et al., 1994). It is used to evaluate user interface in regards of learnability and was originally designed as a tool to evaluate walk-up-and-use systems like ATMs or kiosks where users have little or no trainings. The main purpose of the cognitive walkthrough is to find out the ease of learning of a system, this can be achieved by navigating through the interface. It can be applied at any stage of the design process, as long as the user interface has already been specified. It takes explicit account of the user’s task, and is quick and inexpensive to execute. This method involves breaking down the required tasks a user has to perform while interacting with the system. The same sequence will be taken by any caregiver who wants to use our device to view information regarding the patient. Using the prototype created in Appendix 1 (mobile interface), we performed a cognitive walkthrough using the persona of Amanda Andresh. Each step of the responsive action taken on the mobile app was taken from Amanda’s point of view, to determine if she would encounter problems while using the application interface to respond to an emergency call. Task: Respond to an emergency call. User: Amanda Andresh uses her smartphone and is very familiar with our app. Table 1

Task	Sequence of Tasks
1	Receive alert
2	Tap on respond option
3	Activate camera
4	Select a particular camera view
5	Call ambulance/patient.

The cognitive walkthrough process involved asking the following questions for each of the above actions and determining their success or failure. 1.Will the user know what to do? 2. Will the user see how to do it? 3. Will user see the desired result when they chose a particular action? Materials needed: The following materials will be needed for the purpose of this process; - A representation of the user interface (Appendix 1s). - A persona (Amanda). - A list of tasks that will be used in the walkthrough process - A form for reporting and listing design ideas. Participants: For the purpose of this report, the following plausible roles were carried out and performed in rotation: - Facilitator: Ensures that the walkthrough team is prepared for the session and follows the rules. - Note taker: records the output of the process and also makes comments. - The assessor: conducts the test and interacts with the user asking the four questions. - User: performs the listed tasks. - Product expert: answers questions that members of the team may have about the features or feedbacks of the system. The results of the cognitive walkthrough are seen in the report below and conclude that the prototype’s interface is adequate. The above three questions were asked for each task Amanda would have taken in order to respond to an emergency alert from the fall detection system and answers were “Yes”. Common Problems and Disadvantages: There is no clear-cut guidance about choosing tasks in cognitive walkthrough as regards to what real users will do (Jeffries et al., 1991), though there are suggestions that tasks be chosen on the basis of requirements, needs analysis, and market studies but these are not first hand information. Also the value of the data is limited by the skills of the evaluators, therefore tends to produce a relatively superficial analysis. The severity of identified problems is not estimated by this method (Usabilitybok.org, 2018).

Portfolio item: Cognitive walkthrough

Scenario Amanda Andresh is taking care of an elderly person in a care home where she works as a support worker. She is very familiar with the use of web app. She has the fall detection app installed on her smartphone as mandated by the home she works with. This shows a cognitive walkthrough of Amanda Andresh in responding to an emergency call. Assumption Amanda is assumed to be very familiar with smart devices and mobile applications which she uses regularly. Task: To respond to an emergency call. User: Amanda Andresh who uses smart phone and is very familiar with web app. The steps to complete the respective tasks are given below. Analyst: Developer Interface: Home Screen. Step1. Action: User receives alert. System response: The device beeps and/or vibrates. Question: Will the user know what to do? Answer: Yes – She knows that a beep sound signifies an alert message. Question: Will the user see how to do it? Answer: Yes – She will hear the consistent beep sound or feel the vibration of the smart phone Question: Will user see the desired result when they chose a particular action? Answer: Yes – She will be prompted to either receive or reject the triggered call. Step2. Action: User selects respond button System response: Displays option of selecting response mode. Question: Will the user know what to do? Answer: Yes – She is familiar with using a smart phone. It is also boldly displayed on the screen “Please choose response mode”. Question: Will the user see how to do it? Answer: Yes – It is has a red button on the screen labeled “Activate Camera” Question: Will the user see the desired result when they chose a particular action? Answer: Yes, Different camera views will be shown on the screen of which she choses a particular one. Analyst: Developer Interface:  Mode screen. Step 3 Action: User activates camera. System response: Displays different camera views showing customers positions. Question: Will the user know what to do? Answer: Yes – the user is very familiar with recent technologies. Question: Will the user see how to do it? Answer: Yes – She has used different mobile apps and knows how to select an action. Question: Will the User see the desired result when they search for the patient’s data? Answer: Yes - Different camera views will be shown from which she selects one. Analyst: Developer Page:  Camera view. Step 4 Action: User selects a particular camera view. System response: Displays the selected camera view. Question: Will user know what to do? Answer: Yes – She selects the view based on the. Question: Will the user see how to do it? Answer: Yes – She will be prompted to do so. Question: Will user see the desired result when they search for the patient’s data? Answer: Yes - Only the selected camera view will be displayed.  Step 5 Action: User calls ambulance. System response: Displays customer’s position. Question: Will the user know what to do? Answer: Yes – If the situation is critical from the camera view she calls Ambulance else she calls patient. Question: Will the user see how to do it? Answer: Yes – It is displayed on the screen. Question: Will the user see the desired result when they search for the patient’s data? Answer: Yes - It dials Patient’s phone or the EMT and the data is displayed on the screen.

Appendices

Appendix 1

High fidelity Mobile application prototype

Appendix 2

Current applications in this domain

There is a wealth of recent research available on fall prevention and emergency detection devices, as well as other solutions on the market. Lapierre and colleagues (2017, p. 58) analysed 118 studies on the topic and identified ten types of technologies being used for detection, one of them being wearable systems. However, they concluded that the technology readiness level was low for real-life settings with older adults. The world market on fall detection systems was valued at more than USD 358 Million in 2016 and expected to grow at more than 5% p.a. (Newwire, 2017), thus there are numerous companies with different systems on the market. Exemplary, the company “112motion” (2018) provides an all-in-one solution to connect patients, doctors, caretakers and families and detect emergencies like falls. One of the technologies used for the patient is a smart wearable called “FallAlert”, which is connected to a backend and detects falls with algorithms that supposedly minimise the number of false alerts detected. In case of an emergency, a caregiver gets notified automatically, providing information like fall severity and if the wearable user was able to get up. The wearable also allows for the caregiver to call the user to ensure his wellbeing (112motion, 2018). Solutions with goals similar to this one enter the growing market continually.

Current relevant HCI research in the domain

In the realm of HCI, fall detection is a widely researched topic, for our report we chose to focus on the elderly however there is much more. Many researchers aim to design such a system so that every type of user can benefit from it.  For example a research done by Rougier and colleagues explore video surveillance technology on how  “The use of computer vision systems offers a new promising solution to analyse people behaviour and detect some unusual events. In this paper, we propose a new method to detect falls, which are one of the greatest risk for seniors living alone.” (2007).  What captured our attention when we were researching was that most experiments were conducted to design systems for people of all ages and not just the elderly, because of the fact that everyone is susceptible to falling at any moment. Another advanced research that was conducted used body reflection to track the motion of a human in 3D; “this paper introduces WiTrack, a system that tracks the 3D motion of a user using radio reflections that bounce off her body. It works through walls and occlusions, but does not require the user to carry any wireless device. ” (Massachusetts Institute of Technology, 2014).  However, applying these kinds of solutions would require an in depth analysis of how to transform research into reality. Based on that we decided to go for a feasible solution that would satisfy the needs of our users without breaching their privacy while still delivering value to them.

Bibliography

Affairs, A. (2018). Usability Testing | Usability.gov. [online] Usability.gov. Available at: https://www.usability.gov/how-to-and-tools/methods/usability-testing.html [Accessed 2 Apr. 2018]. Andrew Hussey and Brenton Atchison (2000). ‘Hazard Analysis of Interactive Systems’. University of Queensland, Australia. Angel de la O Herrera, M., Luna, A., da Costa, A. and Blanco Lemes, E. (2015). A structural approach to the HAZOP – Hazard and operability technique in the biopharmaceutical industry. Journal of Loss Prevention in the Process Industries, 35, pp.1-11. Baybutt, P. (2015). A critique of the Hazard and Operability (HAZOP) study. Journal of Loss Prevention in the Process Industries, 33, pp.52-58. Furnell, S. (2016). The usability of security – revisited. Computer Fraud & Security, 2016(9), pp.5-11. Handbook of human-computer interaction. Amsterdam: Elsevier. in: Preece, J., Sharp, H. and Rogers, Y. (2015). INTERACTION DESIGN - BEYOND HUMAN-COMPUTER INTERACTION 4E. Chichester: Wiley. Igual, Raul, Carlos Medrano, and Inmaculada Plaza. “Challenges, Issues and Trends in Fall Detection Systems.” BioMedical Engineering OnLine 12 (2013): 66. PMC. Web. 2 Apr. 2018. Jeffries, R. and Desurvire, H. (1992). Usability testing vs. heuristic evaluation. ACM SIGCHI Bulletin, 24(4), p. 40. Kobie, N. (2016). Balancing security and usability: it doesn’t have to be a trade-off. The Telegraph. [online] Available at: https://www.telegraph.co.uk/connect/better-business/security-versus-usability-ux-debate/ [Accessed 20 Mar. 2018]. PQRI (2015). ‘Hazard & Operability Analysis (HAZOP)’. URL:[pqri.org/wp-content/uploads/2015/08/pdf/HAZOP_Training_Guide.pdf]. Accessed on: 2/4/18. Usabilitybok.org. (2018). Cognitive Walkthrough | Usability Body of Knowledge. [online] Available at: http://www.usabilitybok.org/cognitive-walkthrough [Accessed 19 Mar. 2018]. User Interface Evaluation in the Real World: A Comparison of Four Techniques. R.Jeffries, Miller, Wharton, & Uyeda.'CHI ‘91 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pg 119-124, New Orleans, Louisiana, USA — April 27 - May 02, 1991. Wharton, C., Rieman, J., Lewis, C. & Polson, P. (1994). The Cognitive Walkthrough: A practitioner’s guide. In J. Nielsen & R. L. Mack (Eds.), Usability inspections methods (pp. 105-140). New York: Wiley. Wixon, D. and Wilson, C. (1997). The usability engineering framework for product design and evaluation in: Helander, M., Landauer, T. and Prabhu, P. (1997). Woods, D. (2018). Why Security Without Usability Leads To Failure. Forbes. [online] Available at: https://www.forbes.com/sites/danwoods/2013/03/11/why-security-without-usability-leads-to-failure/#4531e3b44533 [Accessed 20 Apr. 2018].