You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 37 Next »

 GR3 - Paper Prototyping



Table of Contents

User testing

Briefing

These are the rough briefings we provided to our users to set the scope of the testing sessions and to describe the two user roles we tested. None of our users had experience in either of our two roles, so our briefings and common knowledge about the emergency medical environment were the only background that our users were exposed to.

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

We recorded detailed notes about each of our six users (who took on 12 roles)---the actions they took, difficulties they encountered, and comments they made. Here, we've summarized our low-level notes and added higher-level analysis on what came out of the testing.

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:
TODO

User 3:
TODO

User 4:
TODO

User 5:
TODO

User 6:
TODO

Analysis

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). User 1 also had interesting comments on the representation of responsibility in the interface.

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.

TODO: expand the analysis to take into accounts the notes for the six users.

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

Our prototypes were a combination of printed and hand-drawn interface components. We had three main "screen" images which were designed digitally and printed, onto which we placed a variety of components, ranging from text fields that the user could write in to rows of data manually generated as the user tested the interface.

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.

Prototype

 





Testing

 




 

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. Specifically, we 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. 

  • No labels