...
| Info | ||
|---|---|---|
| ||
We recorded detailed notes about each of our six users (who took on a total of 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:
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.
To be expanded.
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). User 1 also had interesting comments on the representation of responsibility in the interface. 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.To be expanded.
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.
...
The second round of iterations focused on the input format of the "Add Medication" form. Specifically, we 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:
To be expanded.
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. To be expanded.