Part 1:
Note: All names are fictional to protect the identity of the individuals interviewed
Questions that I had initially planned for the user interviews can be found here. I found that I deviated from my questions a lot during the actual interviews. In fact, I quickly found many of my prepared questions were not relevant to the particular subject.
User story: Nurse who wants to use a smart device to obtain patient information and treatment recommendations.
Jane is a nurse who works at multiple CVS health clinics throughout the Bay Area. She has worked at large, public hospitals in the past when she was in nursing school. She was busy during the week, but I was able to schedule an interview with her outside of her work hours at my own apartment.
Key Takeaways:
- She currently uses Epocrates, an iPad app, during patient visits to lookup available treatments and check for conflicts between drug interactions. The iPad app is used rather than the iPhone version because she needs a larger screen for the reasons to follow.
- One of the most important things she has to do is to establish trust with her patient. This means she needs to be able to share information with her patient, often by showing the patient her screen. Showing a wearable may be infeasible.
- She needs to be able to view multiple available treatments so that she can understand the tradeoffs between options. This means that output will contain a lot of information.
- She does not always know patients’ health issues prior to arrival, so she needs to spend time learning about them in real-time. This means that she needs to input new information.
- Patients often have concerns about privacy. Spending too much time interacting with devices instead of with the patient can cause distrust.
- When she is conducting a test, her hands can’t be used for other tasks.
Details:
I asked Jane about her workflow. Because her clinic accepts walk-ins, she often does not have time to lookup the patient’s medical history prior to arrival. The first phase following the arrival of a patient is discovery. She first spends on average five minutes listening to the patient describe his/her current symptoms. She then asks about the patient to describe his/her medical history and any other drugs that are currently being taken. The next phase during a patient visit is the check-up. During this phase, she conducts tests on the patient. The most common tests that she performs are for strep, pregnancy, flu, urine analysis, and sugar and cholesterol. If her own findings confirm what the patient described, she moves on to the next phase, treatment lookup. If her findings conflict with what the patient described, she goes to her computer to lookup the patient’s medical records. In complex scenarios, she sometimes needs to call the patient’s doctor.
During treatment lookup, she types in the main problem into her iPad app. The query is a keyword search such as “urinary tract infection” that returns multiple treatments that are available. She generally knows which to select and prescribe, but sometimes she needs to cross-validate with a separate search for multiple drug interactions. Sample screenshots of the app are below:
In general, a query will taken only 15-20 seconds. If she needs to check for drug interactions, it will take her an additional 30 seconds. Looking up a patient record on the computer, if needed, takes about a minute. Of course, while these numbers should be taken with a grain of salt since she has never timed them herself, it is reasonable to conclude that these tasks are not time consuming.
User story: Person who uses a smartphone to keep track of his/her statistics while exercising.
Steven is a middle-aged marketer whom I met at Willard Park during “Yoga in the Park”, which is a community yoga event hosted by Lululemon.
Key Takeaways:
- Steven does both involved and casual exercises. Thus, while he wants to use specific applications (distance /speed tracker, calorie burn tracker, etc) that are tailored for involved exercises, he also accesses common applications (e.g. email) when he is doing casual exercises. To meet all of his needs, a wearable device should provide multiple functions and be general (aka. not highly specialized like the Fitbit).
- “The main thing that I want to do with my phone when I’m hiking is to not use it”. Steven’s comment suggests that he does not want to always be thinking about his phone. A wearable should be able to provide information quickly when he is interested in getting information, but should otherwise be non-intrusive.
- Applications that he current uses when exercising are: a workout routine app, voice memos, email
- Applications that he wants to use when exercising are: track current temperature, calories burned, distance traveled, and speed.
Details:
Steven exercises about 1-2 times a week. Thus, I would consider him to be a casual exerciser. He is health-conscious, but does not want to devote a lot of time to fitness activities. This suggests that any wearable, fitness application should not require a lot of direct user input. When he does exercise, he does yoga, hikes, jogs, and does push-up and ab workouts.
For his ab and pushup workouts, he uses an app called “Fitness Builder” on his phone that provides different video routines for a set amount of time. He first clicks the app, selects a customized workout that he has set-up beforehand, hits “begin”, and then sets the phone next to either his feet or head. As he does each exercise, he listens to the app to determine 1) what exercise he is doing, 2) the rep count and 3) the rep pace. He needs to adjust his body based on the current exercise in order to visually consult the video that plays on his phone. For example, if he is doing situps, he will sit with his feet next to his phone so that his eyes are facing the video. When he is doing pushups, he would turn around so that is head is near the phone. When he is done exercising, he simply stops the routine on his app, and his workout routine is automatically recorded by the app for the day. Thus, he does not need to manually enter the exercises that he did.
Steven does not currently use his phone when he does yoga nor when he is jogging. He does not use it for yoga because he has not found a need for it. He does not use it while jogging because he says that “it is awkward to pull out [his] phone while he is running”. When he is hiking, he uses it for non-fitness-related activities such as recording voice memos of reminders, ideas, and stories for his own reference later. He also constantly checks email out of habit even though there is often no network reception. This suggests that Steven would be interested in a wearable that notified him whenever he got an email so that he does not need to check blindly.
Part 2: Brainstorm and Prototype
Brainstorm:
1. An app that helps medical professionals perform injections. A common cause of illnesses in patients is when doctors and nurses prescribe or apply incorrect medication (Source: http://www.nolo.com/legal-encyclopedia/medical-malpractice-common-errors-doctors-hospitals-32289.html). Such an app would help prevent this by automatically comparing the injection substance with the patient’s record via a short range emission mechanism (e.g. RFID) and display the results to the medical professional on his/her watch. I imagine this to work the following way:
- Each substance cartridge would contain an RFID tag that identifies what the substance is.
- The smartwatch would receive this data and compare it with the patient’s record. Then it would either alert the doctor if the substance is incorrect or of the wrong amount, or it would indicate a progress bar if there is nothing wrong.
2. An app that alerts when and where the next patient to check-up on is, as well as provide an option to quickly contact the doctor.
3. An app that receives a patient’s temperature when a thermometer is used. Afterwards, the app would a graph showing historical data and provide a color-coded indicator to signal whether the person is healthy or unhealthy.
4. A patient puts on a smartwatch that can measure blood pressure and display back the results. The results would automatically sync with a nurse’s iPad or computer. This pattern where a patient wears a watch that displays the results of a test helps solve the trust issue described previously by involving the patient through the entire diagnostic procedure.
5. A smartwatch app that measures a patient’s heart rate, skin temperature, and environmental oxygen and carbon dioxide levels through sensors embedded in the watch. All of this data is sent over the network, and would alert a nurse or doctor if there is an irregularity.
6. A smarter WebMD: A patient can describe his/her symptoms to a smartwatch app. The smartwatch app would use the IBM Watson Q&A API to suggest possible illnesses that the patient is suffering from based on the symptoms input. If no results have a high prediction confidence level, the app would help the user schedule a doctor appointment.
7. An app that would allow a nurse to track the status (vital signs) of his/her patients. Irregularities and patient requests would push alerts to the watch. This app would allow a nurse to be reached as long as he/she is wearing the watch.
This is my favorite idea because it takes advantage of the smartwatch form factor the most by solving the problems of 1) nurses’ hands are often occupied and 2) they need to be available to help patients at all times.
8. Diet tracking app: either use NFC or a barcode scanner built into the watch to obtain nutritional information from products (note: this assumes that such information will be encoded into these products). This is a much easier way to input purchase information as opposed to pulling out your smartphone and then recording.
9. A smartwatch app with hardware that would allow it to detect allergens.
10. An app that allows a person to quickly check the health statuses of family members and close friends.
11. An app that specifically tracks a baby’s status. For example, it might be able to have a live feed to a baby (audio/video) monitor. It can also alert a parent to things like the baby’s location, when the baby would need to be fed, etc.
12. Prescription reminder app: reminds someone when they need to take his/her medication, when prescription is running low, and possibly even speed up the prescription pick-up process by exchanging health insurance information quickly.
Prototype:
Prototype Test Summary:
Motivation for app:
Based on my initial user interview with Jane, the nurse, I wanted to create an app that would provide a nurse with faster access to patient data prior to the arrival of a patient. This would give a nurse more context surrounding the visit, and also reduce the amount of time spent asking about a patient’s health history - a big pain point that I discovered during the user interview.
Prototype Test Subject:
For the prototype test, I found a medical assistant who volunteered at Lifelong Medical Care Clinic. As a medical assistant, she has shadowed both doctors and nurses.
Test Set-up:
Before I showed her the device, I described the purpose of the app, as well as who the target user would be. I said that the app would be used by nurses to help monitor patients’ vital signs. There would also be a notification system that would allow patients to ping nurses when they had problems. After providing this background, I gave her the prototype and asked her to walk through the screen flows while I watched quietly.
Prototype Test Key Findings:
- I discovered that my idea for the app was fundamentally flawed for use at large hospitals. I intended the app to provide a patient dashboard that would allow a nurse to constantly monitor, on her own volition, the status of her patients in order to provide preventative care. However, my tester pointed out that nurses at large hospitals simply have too many patients who check-in and out too often for a dashboard to be usable. Instead, shifting the emphasis towards a patient alert system would provide more value.
- Just because the app is on a watch doesn’t automatically mean that it is easily accessible. My tester pointed out that nurses are often holding things so that the outside (back of the hand) would be facing away from the body. Thus, in order to view the watch, a nurse would have to twist his/her arm in towards the body, which could cause the nurse to spill whatever he/she were holding!
- My tester helped me discover that I had not put any privacy controls in place. Just because a watch is worn on the body and therefore difficult to lose, doesn’t mean that no security settings are needed! The challenge in solving this problem would be striking a balance between allowing information to be constantly available without user interaction, yet ensuring that only authorized eyes can view the data.
- She pointed out that while knowing a patient’s vital signs is helpful, a nurse would still need to go directly to the patient to understand the entire situation better. Thus, more value can be derived from helping a nurse get to the patient as quickly as possible.
Smaller Usability Bugs:
- She had no idea what my buttons did. “Is there a back button?”
- Nurses work in different units and thus their needs and behaviors will be different. For example, a nurse working in an ER may have very little time to provide input to a watch at all, while a nurse working in an eye care unit will have more time to absorb information.
- How would a nurse be informed of an alert? A vibration? Sound? How strong will this vibration be?
- An alert should provide at least the following information:1. Who requires assistance?
- I didn’t know this before, but doctors also need to get in touch with nurses. Thus, an alert system should be built around doctor→nurse communication.



Comments