Table of contents:
| Table of Contents |
|---|
Design
Final Design
Here we present several screenshots of our final design along with a discussion of our key design decisions along the dimensions of Learnability, Efficiency and Safety. It is important to mention up-front that we designed this interface with the idea of a tablet in mind as we felt that the portability of our user interface would improve it's usefulness to the clinical staff. Throughout this interface, we will demonstrate only the doctor's view. The reason for this is because the nurse's view is a subset of the doctor's view. The difference being that the nurse cannot prescribe medications.
Figure 1: EZ-ICU Main screen.
General Design Thoughts:
Given the user population and environment we were targeting - busy doctors and nurses in the ICU - we made our user interface as simple and intuitive as possible. It was particularly important to provide a comparable level of learnability and efficiency to what the classical whiteboard provides, without any of the safety pitfalls. Hence, the main screen of our interface was designed to provide clinical staff with an intuitive overview of the patient population and provide strong information scent on how to dig further into individual patient details. As we will discuss further into this section, we incorporated several simple, but informationally dense signifies on the page.
...
Figure 2: Patient Information view
General Design Thoughts:
Once a user clicks on a patient tab, the tab opens to display an expanded set of information about the patient as shown in figure 2 above. This design allows the clinicians to maintain their overview of the breadth of patients in the ICU, even as they are seek more depth on a one specific patient.
...
Figure 3 A: Prescription Screen
Figure 3B: Prescription Screen
General Design Thoughts:
...
- Learnability
- Structure of the UI changes minimally as user navigates across patient tabs.
- There is strong information scent that users can add new prescriptions.
- When adding new prescription, frequency is listed in linguistic terms that doctors typically use - every hour, every week, etc.
- Text input contained greyed out values communicating what should be inserted.
- Efficiency
- Summary information on all doses is displayed.
- when the start and end portions are clicked, a handy calendar pops us to help with selection of the start and end times.
- The medication utilizes auto-complete
- Safety
- Prescriptions may not be edited, only canceled and reissued with new values or dosing intervals.
- Accidentally canceled prescriptions may be undone.
Figure 4A: Administration Screen
Figure 4B: Administration Screen:
General Design Thoughts:
Once a user clicks on a the administration screen, a list of time ordered dosages which need to be administered are shown. simply click the "done" button to verify that the dose has been given, and the user interface updates accordingly.
...
- Learnability
- When the user clicks done - there is immediate visual feedback telling the user when the dose was given and the dosage indicator in this case went from red to green
- Safety
- Accidentally clicked administrations may easily be undone.
Important Design Decisions
Here we discuss design decisions we made which were motivated by the three evaluations we did
Paper Prototyping
*Issue 1: * Users couldn't see patient allergy information when prescribing new medication
Design 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
Design Fix: Make the Overview screen role-dependent, and switch "Add Medication" to Administer Tab with simple indicators.
*Issue 3: * Users were unsure of the input format for "Frequency", "Start", and "End"
Design 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.
Design Fix: Added text indicators along with the alert icons.
Issue 5: The prescribe medication was a pop-up menu which users found annoying as it blocked parts of the screen they wanted to observe - such as patient information.
Design Fix: We eliminated the pop-up and placed the prescribe portion within the main pane of the interface.
Heuristic Evaluation
There were several fantastic points of feedback we received during the Heuristic Evaluation session, here we highlight the ones we felt were most useful and the corresponding design fixes to our interface.
Issue 1: Users could not sort patients by those needing the next dosage.
Design Fix: We added this functionality into by allowing various sorting options in the UI.
Issue 2: Our color indicators and accompany test accompanying text were confusing users of the interface. The interface used to display a red indicator and say how many minutes ago the dose was due. users were confused about weather the "ago" referred to their own administration, or what was due.
Design Fix:
User Testing
Considered Design Alternatives
Implementation
The EZ-ICU interface is designed to be a persistent, dynamic, client-side interface. Since we had no need for complex server-side logic or interfaces with other systems, we decided to create our entire application without a traditional backend. We chose the backbone.js library to handle data storage and the overal architecture of the program. Backbone allows us to be clear about specifying the models and views in our application, and allows persistence of those models. For testing purposes, we can use backbone to store patient information on the user's machine, using Local Storage, but backbone also supports synchronization to an external server, which might be necessary for future implementations of the project.
The primary advantage of this decision is that absence of a centralized server means there is one less component which can fail when users interact with our application. Users can note the administration of medication and see patient status, even when offline, and they are never stuck waiting for a server response or dealing with internal server errors. On the other hand, the local storage method means that users on different machines will have no way to see one another's data. Full implementation of backbone.js synchronization to a server would solve this problem.
We used several other recent web technologies to make development of our application easier. We chose coffeescript, a language which compiles directly to javascript, as our primary language for the application due to its cleaner syntax and support for modern programming paradigms like list comprehensions. Underscore.js provided functional programming tools and a templating system which allowed easier separation of our data from the presentation of that data. Sass gave us cleaner stylesheets with nested selectors and less repetition of information. Finally, moment.js provided easy handling of dates and times, along with natural language display of times such as "a few seconds ago" or "in 4 hours".
Evaluation
To evaluate our platform, we interviewed three emergency care clinicians who were personal contacts of the group members. We believe that these users are representative of the target user population.We provided all users with a briefing and a set of tasks to be performed using our platform. This briefing is shown in the briefing section below. For each usability problem identified by the interviewee, we provide a severity rating and discussion of how this issue was address in the final implementation.
Briefings
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 Task 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 Task 2: Nurse
- You want to check in on patient Kamran 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
Usability Tests
Below we show the results of our usability test on the three users, severity scores include: cosmetic, minor, major or catastrophic and are clearly denoted. For each usability issue identified, we discuss our implemented solution.
User 1:
Task 1:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
Task 2:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
User 2:
Task 1:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
Task 2:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
User 3:
Task 1:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
Task 2:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
Reflection
We changed the wording of the interface from "ago" to "overdue" to address this concern.
Issue 3: There was no easy way to sort prescriptions.
Design Fix: Prescriptions are now displayed in alphabetical order.
Issue 4: No auto-complete when prescribing medications.
Design Fix: We implemented auto-complete fro the nonprescription.
Considered Design Alternatives
As we went through this project there were several alternative designs that we considered implementing. For a complete depiction of these, please see the GR2 section of this wiki which includes storyboards that accompany what we believed were our strongest designs. Of the proposed design alternatives the one we considered most strongly considered was a smart-phone style interface which was functionally very similar to what we have implemented in our design above with the exception that it did not contain the information sidebar and the patient menu, once clicked, expanded to occupy the entire screen. Ultimately we decided against this design because we felt it required far too much navigation and didn't allow the clinical staff as much access to information at a glance, which is highly important in a critical care context.
Implementation
The EZ-ICU interface is designed to be a persistent, dynamic, client-side interface. Since we had no need for complex server-side logic or interfaces with other systems, we decided to create our entire application without a traditional backend. We chose the backbone.js library to handle data storage and the overal architecture of the program. Backbone allows us to be clear about specifying the models and views in our application, and allows persistence of those models. For testing purposes, we can use backbone to store patient information on the user's machine, using Local Storage, but backbone also supports synchronization to an external server, which might be necessary for future implementations of the project.
The primary advantage of this decision is that absence of a centralized server means there is one less component which can fail when users interact with our application. Users can note the administration of medication and see patient status, even when offline, and they are never stuck waiting for a server response or dealing with internal server errors. On the other hand, the local storage method means that users on different machines will have no way to see one another's data. Full implementation of backbone.js synchronization to a server would solve this problem.
We used several other recent web technologies to make development of our application easier. We chose coffeescript, a language which compiles directly to javascript, as our primary language for the application due to its cleaner syntax and support for modern programming paradigms like list comprehensions. Underscore.js provided functional programming tools and a templating system which allowed easier separation of our data from the presentation of that data. Sass gave us cleaner stylesheets with nested selectors and less repetition of information. Finally, moment.js provided easy handling of dates and times, along with natural language display of times such as "a few seconds ago" or "in 4 hours".
Evaluation
To evaluate our platform, we interviewed three emergency care clinicians who were personal contacts of the group members. We believe that these users are representative of the target user population.We provided all users with a briefing and a set of tasks to be performed using our platform. This briefing is shown in the briefing section below. For each usability problem identified by the interviewee, we provide a severity rating and discussion of how this issue was address in the final implementation.
Briefings
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 Task 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 Task 2: Nurse
- You want to check in on patient Kamran 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
Usability Tests
Below we show the results of our usability test on the three users, severity scores include: cosmetic, minor, major or catastrophic and are clearly denoted. For each usability issue identified, we discuss our implemented solution.
User 1:
General Feedback: When we performed this user test, we observed that our user struggled the most at the administration of the dose. Otherwise, the user completed the tasks quickly and efficiently. When asked what their general impression he was generally complimentary about the design and utility of the interface, but felt it needed some more work to maximize it's efficiency in an ICU setting. Here we will present the usability problems and solution we might implement to address the issues brought up in this usability interview.
- [Major] There is no search bar when a clinician can look for specific patients.
- [Minor] In the prescriptions menu, the user didn't like that bogus units could be entered.
- [Minor] In the prescriptions menu, the user suggested moving the "now" button to the top and making it more prominent .
- [Minor] In the prescriptions menu, suggested allowing multiple formats of entry: "I want to give 10 tablets, one every n hours."
- [Minor] In the main menu, If you click the red indicator on the right of the patient, it should link you to the administration screen.
- [Cosmetic] The overview information should be moved to the sidebar, and the prescriptions/ administration information should remain where they are.
What we would plan to address:
We agreed with several of the usability problems that User 1 pointed out. In the next cycle of our iterative design process we would likely incorporate all of his feedback into the next version of the interface.
User 2:
Dr. X is a young radiologist who often works in ICU, and has very good IT skills.
General Feedback: We first gave a very brief explanation of the scope of the application to Dr. X, then let him use the application without interfering, simply writing down his remarks. Dr. X found the application is straightforward to use. Within a few minutes he had understood how it works, both from the physician and from the nurse standpoint. He gave us a few advice/remarks:
- [Major] In order to to assess patient Mohammad, the user wants to see the previous observations on the patient. This issue is inherent to the fact that we have narrowed the scope of our application.
- [Minor] The user dislike having to scroll down the right information box. The user would prefer that the application had hidden some non-important information such as the patient's address, so that he can focuses on the most useful information.
- [Feature request] In the vital signals, it would be good to display the patient's temperature. As the temperature isn't taken regularly, it should go along with the time at which it has been taken.
- [Minor] The patient's photo is nice shouldn't appear by default as it is not frequently used.
- [Major] The user found a bit surprising that the application maintains two different list of medications: other medications vs. prescriptions. In the ICU, most patients are able to medicate themselves so it would probably makes more sense to add the other medications within the prescriptions.
- [Major] When adding a new prescription, the physician has to indicate in which units the dosage is expressed. This could lead to dangerous typo (e.g. g instead of mg).
- [Minor] Related to the previous point, usually the dosage is indicated within the drug's name, e.g. "Aspirin-100" stands for aspirin 100 mg. Not only does this prevent typos, but it also allows the physician to prescribe drugs that are available in the hospital's drugstore. For instance prescribing Aspirin 150 mg would be difficult to administer if only Aspirin-100 and Aspirin-200 are available.
What we would plan to address:
Dr. X pointed out some very interesting issues, which we would definitely take into account in the next release of the application.
User 3:
Dr Y. is a young ICU physician, working in France.
General Feedback: General Feedback: We first gave a very brief explanation of the scope of the application to Dr. Y, then let him use the application without interfering, simply writing down his remarks. Like Dr. X, he didn't have any blocking issue when using the application. . He gave us a few advice/remarks:
- [Minor] In the right box, having the Patient History is much less interesting than the patient's immediate history.
- [Major] When adding a new prescription, the 'dosage' should be compulsory. Right now we can add a new description that have no dosage, which doesn't make much sense.
- [Minor] When adding a new prescription, we can specify a start date which is posterior to the end date.
- [Cosmetic] In the administration panel, it is very unlikely to undo a drug administration that has been performed a long time ago. It might be useful to add a confirmation message.
- [Major] When adding a new prescription, the frequency should be more flexible, perhaps by adding a custom text if needed. E.g. It is commonplace to prescribe a drug for the morning and the evening.
- [Feature request] The dosage can sometimes be variable, either increasing or decreasing over the time, depending on the evolution of the patient. Even more intricate but also commonly used, it is sometimes up to the nurse to decide what dose to administer to the patient. For instance, if the physician has prescribed more fine for a patient, the physician might simply say to the nurse to apply the usual protocol when administering morphine, which gives the nurse flexibility on the dose, and also the patient is given a morphine pump that he can use to medicate himself according to how much pain he feels (obviously such a device is limited so that a patient cannot put his life into danger).
What we would plan to address:
Dr. Y pointed out some very interesting issues, which we would definitely take into account in the next release of the application.
Reflection
As with many project-based classes, there is always a tradeoff between starting a project too early (which risks locking onesself into decisions without enough knowledge or experience) and starting too late (which risks not being able to follow through on a great idea). As a group we tried to balance these two aspects, and we were generally successful at applying the design skills from the course to the project without pushing everything to the last minute. That said, we were hesitant to throw away good work which we had done previously, which may have hindered our ability to be creative and innovative. During the paper prototyping, we designed a variety of possible interfaces, and our final design ended up very closely resembling one of those paper interfaces. Our user testing and evaluations seemed to indicate that we had chosen well, but if we had encountered serious usability problems with that design, we might have had trouble letting it go and starting over from a different idea.
One change which might have helped us ensure that we were not locked into a single design would have been to develop and test paper prototypes for several of our initial designs, rather than focusing on one. Allowing users to interact with two or three different paper designs would have given us a great deal of new information about the usability of different aspects of our designs, and would also have allowed us to explore a broader set of possibilities without the commitment of a functional computer interface.
That said, we are all proud of the design we have produced and the work that went into it, and our users seemed pleased with the results as wellDiscuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.