GR3 - Paper Prototyping

Table of Contents

User testing

Briefing

User role 1: Doctor

You are a doctor at Massachusetts General Hospital, and you are making your rounds in the Intensive Care Unit (ICU). You move from patient to patient, analyzing their conditions, making appropriate diagnoses, and, when needed, prescribing appropriate medication based on the patients' status and treatment.

User role 2: Nurse

You are a nurse at Massachusetts General Hospital, and you too are making your rounds in the Intensive Care Unit (ICU). Like the doctors, you move from patient to patient. As a nurse, your focus is on checking vitals, monitoring patient condition, and administering prescribed medication and treatments.

Scenario tasks

User role 1: Doctor

• You want to assess patient Mohammad and prescribe a medication
• You need to prescribe 100mg Aspirin every hour for the next four hours
  • You need to make sure that the patient is not already taking aspirin
  • You need to remove any other medications that the patient is taking
  • You need to ensure that the patient is not allergic to aspirin
• You need to verify that the task was accomplished

User role 2: Nurse

• You want to check in on patient Mohammad and determine if he has any upcoming medications
• You need to administer the medication to the patient
• You need to indicate that the medication was administered
• You need to verify that the task was accomplished

Observations

Notes

User 1:
User 1, a male with little background experience in medicine, started with the doctor role. He quickly knew to tap the patient's name and "Add Medication". He stumbled on the format of the "Frequency" field, but otherwise handled the "Add Medication" dialog box well. He seemed to quickly understand that the "X" next to each row of medication removed that row. He scanned the "Add Medication" dialog box for patient allergy information, and explicitly mentioned that he couldn't find the information he was looking for before realizing he had to return to the previous screen to learn about the patient. The user then switched roles to evaluate the nurse scenario. He brought up an interesting difficulty: he was unsure if the interface represented actions that would be performed automatically, or if they were actions that were his responsibility. He also had a little bit of difficulty understanding what tapping the medication pane should do. Otherwise, he completed the nurse role without issue or pause.

User 2:
User 2, a female with little background experience in medicine, also started with the doctor role. She knew immediately to tap the patient's name to proceed, and did a quick scan of the resulting page to find "Add Mediation". The user first tapped an empty row in the schedule to add a prescription before seeing the form at the bottom of the page. The user added the aspirin prescription without issue (except a slight trip-up on the formatting of the "Frequency" field). The user noted the inconsistency inherent to removing medication (as she was asked to do) within a modal page she reached by tapping "Add medication." She was able to quickly confirm her actions on the Overview page. The user then began the nurse scenario. The user saw that it was time to give medication and quickly found the "Give Medication" button (changed from "Add Medication" in a mid-testing iteration). The user was unsure of why future doses were not appearing in the "Upcoming" table present on the page. She also questioned what "Alerts" were and what they meant, as it was unclear to her from the interface. Despite the lack of affordance, the user tapped on the medication pane itself (which we had originally intended to be for data output only, but chose to allow the user to proceed to medication management after tapping it). She was able to complete the remainder of the tasks without issue.

User 3:
User 3, another female with little background experience in medicine, started with the nurse role. She immediately found the "Give Medication" button after tapping on the patient's name. She tapped the "Done" button next to the relevant row in the table, and vocalized her appreciation for the immediate feedback present in the page (our "computer" removed the row for the medication as soon as "Done" was tapped). As a doctor, the user noted the parallels she saw to the nurse's Overview screen, and found Mohammad's patient row without a problem. The user first removed the previous medications and knew (with the iterated form) what to put in the "Frequency" (drop-down), "Start", and "End" (date/time pickers) fields. The user chose to confirm the prescription within the dialog box rather than on the Overview screen. She notes that she would "check back later" and questions "what are alerts?" before tapping the Alerts tab. She was confused by confirming medication and by the opening of the "Give Medication" modal page when tapping on "Alerts" as a doctor (she correctly thought that the page was meant for nurses).

User 4:
User 4 was a male, again with no medical training. He was able to accomplish all of the given tasks, but had difficulty with determining whether the patient was allergic to aspirin while on the "prescribe medication" screen, indicating that we need to ensure that information is prominently visible at all times. He also suggested that we make the modal information of the current user's scope of responsibility (doctor or nurse) more clear. He had some trouble finding the correct affordance to click to bring up the "Give Medication" screen. 

User 5:

User 5 was a female with emergency medical training. She accomplished both user roles' tasks quickly and easily, but had two concerns that hindered her progress. First, as with many of our users, she found the "frequency" input unclear, but when it was replaced with a dropdown menu she found it much more understandable. Second, she felt that she wanted to ensure that there was some indication of the patient's immediate medication history in the sidebar so that it could be accessed from anywhere, especially in case she needed to find out if the patient had received any medication prior to ICU admission. 

Analysis

Overall, we were pleased with our users' ability to navigate the interface. All the users accomplished all of the provided tasks correctly, and there were no errors in the prescribed or administered medications. The primary problems that our users faced were in locating context-dependent information such as patient allergies and in locating the correct buttons to activate the "Prescribe" and "Administer" interface elements. 

User 1's troubles with finding the patient information while prescribing a new medication led us to consider the role of the patient information sidebar, and the value of context in our interface. Our eventual conclusion was that the patient information sidebar provided context which was valuable in any mode of the interface we were testing, and we decided to have the sidebar present and visible throughout all of the screens (adding consistency and context). This ensured that the patient allergy and history information was always visible to the doctor or nurse, which helped in the correct prescription of medication. User 1 also suggested that the interface should make the current user's scope of responsibility (as a doctor or nurse) clearer.

User 2's recognition of the inconsistency of visiting the "Add Medication" form to remove a prescription has made us consider a more descriptive label like "Manage prescriptions".

User 3 made some helpful comments regarding the newly-iterated prescription form. We've decided that the "Start" field should default to the current date and time, and that units on the "Amount" field should be separated from the numeric value in some way. She also noted some inconsistencies in chronological ordering throughout the application that a later iteration corrected.

The first three users alike all stumbled in some way on the "Add Medication" form, indicating some need for updating the way the fields collect information. Our initial revision had the "Frequency", "Start", and "End" fields as free-form text boxes, but we quickly realized that a richer, more structured input method for these fields could reduce confusion.

Usability issues

Issue 1:
Users couldn't see patient allergy information when prescribing new medication
Fix: Make patient information sidebar visible at all times, providing consistency and context

Issue 2:
Users were confused by "Add Medication" button while performing the nurse task
Fix: Make the Overview screen role-dependent, and switch "Add Medication" to "Give Medication" for nurses

Issue 3:
Users were unsure of the input format for "Frequency", "Start", and "End"
Fix: Provide richer controls to alleviate formatting issues: a drop-down for Frequency, and a date-time picker for Start and End

Issue 4:
Users found the alert icons ambiguous.
Fix: Replace icons with text indicators.

Prototype documentation

Prototype & testing photos

Our prototype represented three screens of our interface: the overview page, the prescribe page, and the administer page. We used card stock and paper to build the mock-ups, and we added interactive elements on top of the printed base layers.

Iterations

Our prototypes underwent two rounds of iteration throughout the testing period.

The first iteration that we made was to change the size, location, and context of the two dialog boxes we mocked up so as not to obscure the patient information sidebar present on the Overview screen. We made the decision to do this after users struggled to find patient allergy information while prescribing a medication, and we thought having the patient information always accessible in the sidebar to be a reasonable approach.

A minor iteration came after the second test user, when we decided to explicitly rename the "Add Medication" button to "Give Medication" for the nurse role. This change introduced the first difference between the doctor and nurse views of the Overview screen, but, after careful analysis, we concluded that differing interfaces might be ideal.

The second round of iterations focused on the input format of the "Add Medication" form. As suggested in the studio section, we changed the format of this screen to an expandable pane, rather than a popup. We also switched from free-form text boxes to more structured inputs for the "Frequency", "Start", and "End" fields. For "Frequency", we supplied a drop-down with choices for the frequency, and for "Start" and "End", we supplied a date-time picker. This reduces confusion about the formatting of the text in those fields. We also added example values, colored light gray, to those fields to indicate the expected type of information, as shown below:

Notes from the Studio Session

There were several useful observations and points of feedback made during our studio presentation. We summarize the most noteworthy of these points below:

1. It was suggested that we consider not using a pop-up window, and keeping all information in a single pane, which would be accessible via a +/-  button for each patient.
2. It was suggested that the dosage history on the Prescribe medication page should be on the bottom right hand side, so that it is consistent with the Administer Medication screen.
3. It was suggested that we change the name of the "Prescribe Medication" window to "Add Medication" and the "Administer Medication" window to "Give Medication" to provide internal consistency with the home screen.
4. One individual stated that the layout of our UI was intuitive, but suggested we include a help button, just in case new users get lost.

We plan to incorporate these suggestions as we develop our computer prototype.