InformalPrototype:Safety GPS
From IEOR 170 Spring 2007
Contents |
[edit] Introduction/Mission Statement
Our project team has developed a solution to deal with the disconnect that exists between the public and the police in times of emergency. Our solution directly meets our group’s mission statement. Namely, our mission statement is:
To Design a device and system that will promote the creation of a safer community.
Our team of upper-class Industrial Engineers has spent the last few months tackling this problem that has increasingly become part of our world’s reality. More and more people are getting attacked and the police just are not responding in time. Our device hopes to reduce if not alleviate this issue.
[edit] Member Roles
Ryan Panchadsaram headed off physically creating the prototype and describing it in words. Chris Ling played a crucial role in the testing process, he not only designed the test script but he also wrote up parts of the method write-up. Rakesh Vij worked in collaboration with Ryan and Chris, helping build the prototype and writing up the methods section of our write-up. Karey was one of the primary observers and he also helped by writing up discussion and results sections of the write-up. Our whole group worked really well together and everyone played an important role in the testing process.
[edit] Prototype
Concept to Prototype
Based on our initial sketches and feedback from our contextual inquiry, we updated our design for our prototype. We established its size, its functionality, and an interaction process. Our lo-fi prototype was created using 8x11 paper, cardboard, markers, super-glue, and lots of tape.
We went through a lot of models, trying to incorporate the features we drew in our concept sketches. One thing we found out early on was that lo-fi prototyping is faster, but still requires a lot of work and attention to detail.
Prototype The prototype that we designed had movable parts and colors to signify its states. At first we were going to build many states, and attempt a “Wizard-of-Oz” approach to test our design; but we felt it was necessary to let the user interact with the device while moving around.
For our testing, we tested the design of the device and not the interface the police would be interacting with. During our contextual inquiry, most of the feedback received was concerned with product design more than the Police System design. We used to following mockup to convey the Police System design:
[edit] Method
Participants:
To help gauge the functionality of our low fidelity prototype we decided to select UC Berkeley participants to test our product. As opposed to family members or other members of the community, our team felt that students would provide us with a good representation of our different users. For example, students engage in similar activities as parents, such as going to local parks or walking their pets. Additionally, students also provide extreme circumstances, such as 2:00 am commutes from the campus. The following is a list of our participants:
Environment:
Our team tried its best to simulate a realistic environment for each participant. We chose to the conduct the interviews in the evening given the higher probability of a participant using our device as a result of the higher night crime rates. While tasks were completed outdoors, the product demonstration and initial briefing was conducted indoors. The only equipment the participant needed was the prototype device.
Tasks:
Our dual roles provided our team with an efficient strategy to document and facilitate the interviews. Running a few practice interviews helped everyone solidify and practice their respective parts. Good follow-up questions were formulated during this session that we asked the participants.
The three tasks (easy, medium, hard) that our team chose tested the functionality of the most important features of our prototype. At this early stage of our prototyping, we were hoping to learn of any insightful information that would help us with future improvements of the Safety GPS. We formulated our tasks based on the most important functions that procedures that could make or break our product with our users.
Our first task asked the participant to activate the warning signal on the prototype. This was the preliminary step that the user would need to do if he or she felt scared or insecure. We hope that this step would be the most intuitive step to figure out, since the other functions would not work unless this first step was completed.
Already in the warning state, the second task was to deactivate the device into its normal configuration. Testing this task was necessary because our users would probably face numerous occasions where they activated the warning state when there was no need for the panic stage. For example, a simple scare from a noise might be a cause that the user would activate the warning state.
The last task was for the participant to activate the device and put it into panic mode. This was the most important task because without a proper panic function, the product would not be that helpful. These tasks represent the 3 most important functions that a user would need to perform. Ideally, the participant will successfully complete the task using only his or her intuition.
Procedure
Our method closely followed the contextual inquiry methods. First and foremost we assigned roles within our group that would ensure the enquiry went smoothly. There were four roles that were assigned: greeter, facilitator, observer, and computer. In our model’s situation there wasn’t much need for the computer role since the prototype itself provides all of the functionality and feedback that our final product will. It is an alerting device and thus as of yet it doesn’t require extensive human-interaction and feedback. However, as a side note we did get the suggestion from multiple subjects that incorporating a siren and/or pepper spray into our device will be additionally beneficial in stalling the criminal while the police comes. Defining the roles first will help understand how the process and method worked.
Greeter: Welcomed the participant of test to our facility and conducts the conventional interview. In this interview we extracted basic information about the subject and their life experiences. Additionally we told them about the product and described the device vaguely since we wanted them to gain most of their insight about the product through their live interactions with our prototype.
Facilitator: The facilitator was the only person who spoke during the actual contextual interview. They led the transition after the greeter spoke and explained to the participant how the demo/test was to work. Specifically, they explained the relationship that our team would maintain was strictly observational. In other words we explained that we were not there to help or answer question, rather just stand back and watch their interactions. Then the facilitator read the demo script to the subject and walked them through the various tasks.
Observer: In this role one of our teammates silently observed and watched the interactions between the test participant and our subject. For the most part this individual just wrote their observations down to be analyzed later. A seemingly simple task, but it required much attention because users have so many actions thus keeping track of them all and jotting them down can be tiresome. However, this task was reduced as there was some help for this person since the computer role was mostly un-needed in our situation so he mostly helped as a secondary observer.
Computer: As was mentioned before this role was unneeded for the most part in our test since our prototype sufficiently provided all the feedback and managed the interaction between our participants and our product. Thus the person in this task mainly helped the observer with his tasks and took pictures while the test was in progress.
Our roles were described and prescribed to our group members (Ryan, Karey, Chris, and Rakesh) during our training before the participant arrived. We felt that the tests would be more substantial and unbiased if we conducted all of our interviews separately. Also since everyone was already well versed with the roles and script from our practice runs/training we decided to allow different members to experience each of the separate roles in turn. We set up our facility to be Ryan Panchadsaram’s house which is conveniently across the street from People’s Park. Coincidentally this location happens to be one of the scariest and most dangerous parts of Berkeley late at night.
We started the interview by first bringing the participant into Ryan’s room where the greeter spoke and started the conventional interview. Then during the transition we took the test into context (ie we walked outside to People’s Park). Once there in the quiet and dark environment we felt that we were in better context to test our product. The facilitator then read the script and walked the participant through the test. While this was happening the observer took copious notes and the computer helped by also taking notes and pictures. Then once the tasks were successfully completed we took the participants back inside to safety and took a final survey asking them if they had any suggestions or complains about the product. Applying the contextual inquiry method worked very well for us and allowed us to conduct a very successful set of interview and prototype tests.
Test Measures
During testing of our prototype our observer was instructed to take notes and record critical incidents when the occurred. The data for each of the three tasks was kept and then analyzed separately. The testing of our product was used to collect data and measures of our products performance and usability. The results and measures of our test returned to us qualitative results, which can be utilized to improve our product’s design. Below are the measures that our tests provided. Further detail and actual results are shared in the results section and the actual observation sheets can be found in the appendix.
Qualitative Measures: - How usable is the product? - Are users having any trouble understanding the various states or modal functions? - Does there seem to be any frustration with using the product? - Does there seem to be any confusion or misconception of the devices switches or utilization?
[edit] Results
Our demo script ran pretty smoothly with each of our participants. It turned out that none of them had too much trouble interacting with our prototype, which is a good sign – it showed that they could perform a task without being explained how to perform it. However, this also means that, as the prototype designers, we ought to look for other needs that the users may not point out or even realize.
The first participant in our experiment had no problems using our prototype. After we asked her if she enjoyed Berkeley, she admitted that “Berkeley can be pretty scary at times.” After explaining our first and second tasks to her, she seemed to understand everything. The device worked as she imagined that it would have, and she thought it would be just as easy to use under pressure while walking alone at night. One concern she had, however, was that she did not feel confident that the cops would be able to be there soon enough.
The small, sleek, shape of our prototype impressed our second participant. After our demo script, she asked to confirm the difference between the “Panic” and “Warning” states. One thing that concerned her was the ability for people being able to track her location, and asked if she could be located when the device was not switched on. Apart from that, she performed all the tasks easily. Afterward, a UCPD actually drove up about a minute later, to our surprise.
Our third participant was also our only male participant. Naturally, he did feel that our device would not be as necessary for him as it might be for other people. Even still, he saw the potential use that it could have, and intuitively figured out how to perform each of our tasks. Overall, we did not have to explain how to perform any given task to any of our participants, which is what we hoped for.
[edit] Discussion
We learned, among other things, that security mattered to our participants. We found that, to our surprise, most of our users probably would not use pepper spray if in a situation that warranted it. Our participants considered pepper spray and mace more of a source of psychological comfort than anything else. We will take this into account in our interface design, and will probably not include pepper spray as part of our next prototype.
What matters is that people feel a genuine sense of security. A false sense of security does little to the good of our target group. Another thing we found is that our participants had differing expectations of the kind of security a device such as ours ought to provide. One did not feel assured that police be there after activating the “panic” state soon enough. Another preferred that the attacker have some way of knowing that police are on their way. The third participant thought that getting people to come provide help should be the primary goal, whether or not the victim or attacker know it or not.
In light of these facts, it was difficult for us to discern the extent to which the user, the attacker, and people nearby ought to be notified of the “panic” activation. The advantages of a conspicuous siren-type noise are obvious. However, such a warning could lead a mugger to attack out of impulse. What this will end up requiring is a careful, user-centered, approach to observing needs, which is difficult to do accurately. Observing someone getting mugged is not something that we can observe everyday, although that is definitely more of a good thing.
[edit] Appendix
Photos from Prototype Development
Photos from User Testing
Security Interface
The security interface will be on a computer connected to a large widescreen monitor. Users can interact with the system by pointing and clicking.
The system is intended to present information in a manner which all the information can be digested in a glance. Our system uses red and yellow circles to denote states of panic and warning respectively. Using colors with similar shapes allows the users to process the information preattentively.
Areas of Interest
When a user hit the panic button on their device, it shows up on the Command Central interface as a red circle. When a user hit the warning button on their device, it shows up on the Command Central interface as a yellow circle.
Basic Functionality
Users can perform basic tasks like viewing the status of a dot and zooming in on the map.
To view the status of a dot, all the user has to do is click the dot.
To zoom on a portion of the map, a user just has to use the slider on the bottom right corner.
Using this information, the dispatcher can assign a patrol vehicle to respond to the scene. If a panic is issued, the only way to remove it from the scene is for an officer to respond.
Future Ideas / Iterations • Integrating police car GPS data to synchronize the information from both systems • Installing system into laptop computers within patrol vehicles • Aggregating warning and panic states can hold useful information for the police department. Looking at the data they can identify the areas which people feel the most unsafe in, and make changes.
[edit] Demo Script
Script of Demonstration (1st draft):
Overview of 3 tasks (easy, moderate, hard) -Explain 1st task(easy) , describe goals - record and log results - Explain 2nd task(medium), describe goals -record and log results -Explain 3rd task(hard), describe goals -record and log results
Script of Demonstration (Final Draft):
Demonstration of Prototype:
Note to Interviewer: After the demonstration, the user will now face a series of tasks where he/she will be asked to perform some of the possible functions associated with the prototype. The scenario of the event will first be described to provide an initial setting. Next, the user will be asked to perform a task that is relevant to the situation.
Interviewer: Now that you’ve seen our initial prototype, you’ll have a chance to use and test our prototype, which will help us gauge its functionality for future improvements. You will be presented with a scenario designed to simulate a realistic environment where this product would be used. In this scenario, you will then be asked to perform a specific task with the prototype. While doing this, please think vocally and ask any questions that you have. Do you have any questions?
1st Task (EASY):
Scenario: After an intense study session at the campus library, you decide to go back to your apartment to take a break and get some rest. It’s 2:00am, which isn’t a night to be walking alone. While you could call for campus security to escort you back, your impatience in waiting for them causes you to start walking first. As you walk off the campus border, you begin to sense that someone might be following you. You realize that you could just be panicking because it’s so cold and late, but you don’t’ see anyone else except for the person that appears to be coming closer and closer.
Task: Initiate the warning function on the prototype…
Note to Interviewer: Take notes as the user performs the above task, making a log of any positive or negative remarks.
2nd Task (Medium):
Scenario (Continuing from the previous scenario): The warning signal has been initiated to notify the UCPD of your signal and location. You continue walking with the prototype in your hand, wishing that you could just blink and be transported to the safety of your apartment. Suddenly, the image of the figure that was following you becomes clearer. As you squint to get a clearer picture, you notice the familiar library employee that you just saw as you left the library tonight. You stop and notice tha t the employee is holding a book in their hand. It turns out that you forgot one of your books in the library and the employee was just returning it to you.
Task: Take the prototype off the warning state and return it to its normal configuration.
Note to Interviewer: Take notes as the user performs the above task, making a log of any positive or negative remarks.
3rd Task (Hard):
Scenario (continuing from the 1st task): The warning signal has been initiated to notify the UCPD of your signal and location. You continue walking with the prototype in your hand, wishing that you could just blink and be transported to the safety of your apartment. Suddenly, the mysterious figure breaks out in a sprint holding a gun, yelling “DON’T MOVE!!” Too frightened to move, you begin to panic.
Task: Activate the panic button on the prototype.
Note to Interviewer: Take notes as the user performs the above task, making a log of any positive or negative remarks.
[edit] Observation Notes
[edit] GPS Safety | Consent Form
We are researchers in the undergraduate class IEOR 170 at University of California at Berkeley. I would like to invite you to take part in our research study which looks at how people use a prototype of our GPS safety design. The goal of the study is to better understand how people will interact and use our product.
If you agree, we would like to conduct an interview of about 20 minutes. We will schedule the interview at your convenience. With your permission, we will audiotape the interview and take still images. We will not take pictures of anything that you don't wish us to.
There are no known risks to you from taking part in this research, and no foreseeable direct benefit to you either. However, we hope that our research will eventually contribute to the design of better technology for the safety of the community.
All of the information that we obtain from you will be kept confidential. Your name and other identifying information will not be used in any reports of the research. Of course, you may still be identifiable to others on the photos.
After this research is completed, we may save the photos and notes for use in future research by others or ourselves. However, the same confidentiality guarantees given here will apply to future storage and use of the materials.
Your participation in this research is voluntary. You are free to refuse to take part. You may refuse to answer any questions and may stop taking part in the study at any time. If you have any questions about the research, you may contact us:
Ryan Panchadsaram (858) 212-2926/ryan@berkeley.edu
If you agree to take part in the research, please sign the form below. Please keep the other copy of this agreement for your future reference.
If you have any question regarding your treatment or rights as a participant in this research project, please contact the University of California at Berkeley’s Committee for Protection of Human Subjects at 510/642-7461, subjects@berkeley.edu.
I have read this consent form and I agree to take part in this research.
_______________________________ ____________ Signature Date
___________________________________ Print Name
