...
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. TODOUser 4:
TODO
User 5: TODOUser 6:
TODO
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 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.
...
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
...