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.
...
- 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 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 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.
...
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 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.
...
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.
Wiki Markup - \[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 . unmigrated-wiki-markupWiki Markup \[Minor\] In the prescriptions menu, the user - \[Minor\] In the prescriptions menu, suggested allowing multiple formats of entry: "I want to give 10 tablets, one every n hours."
Wiki Markup \[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. - [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.Wiki Markup \[Cosmetic\]
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:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
User 3:
| Wiki Markup |
|---|
General Feedback:
Usability Issue 1: \[Critical\] |
Solution 1:
| Wiki Markup |
|---|
Usability Issue 2: \[Aesthetic\] |
Solution 1:
Reflection
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.