Every patient is unique. At Epic, we have created an activity called the "Patient Summary" that has reports that pull in specific data for that patient for the doctor to quickly review. Our current solution, however, does not allow dynamic, on the fly changes for the end user, so this plan was developed to address that need.
+ Improve User Satisfaction with Patient Summary Module by improving UX and eliminating pain points
+ Come up with feasible proposals that can be implemented in on the web platform and will be useful to clinical users
+ Make UI Delightful
UX Task List
+ Research Pain Points
+ Gather Feedback from current users
+ Play around with ideas on how to make functions, no matter how small, easier
Over the course of several months, I worked with the various teams in our InPatient software and participated in user discussion groups, as well as going out into hospitals, such as UW Health.
What we already provide
The first image is a standard report that can be seen in the patient summary activity. The second is a patient facing after visit summary of lab results.
Click images to enlarge>>
We ran our current solutions through this scenario to see how long it could take from just software alone, for a Doctor to have an understanding of his 15 new patients. From this, we mapped out current pain points and how to improve the design.
Critical Problems to address
+ Spacing Issues that impeded context (ex: a 2 column table that spans the entire width of the screen, making it harder for the user to attach the value with the data label)
+ It's really hard to just see what the main problem is with a patient. There is no focus on primary information. All information seems to be given the same weight.
+ What's worse is some information that is important to some doctors is put all the way at the bottom of the page. Some information that should be grouped together is put on different pages. End user has no control over this.
+ "Make the buttons larger" --> What the user meant is that it is hard to see the text on the screens sometimes and they would like the overall text to be larger everywhere
+ Some doctors like data heavy, table view; Others would prefer visuals that show high level data quickly. There needs to be user control over what type of visuals to see.
+ Navigation, call to actions - not standing out; unclear where to go next
UX Task List
+ Suggest style changes in code (ex: instead of 100% width, make width 300 px)
+ Define visuals and communicate them with the entire team so that they can be reused (style guide)
+ Use Drag-and-drop functionality to quickly change views on an end user basis
+ Create controls to switch between different view types (ex: graph vs table, etc)
+ Prototype and present direction about once to twice a month with minor stakeholders. 2 to 3 times a week with major stakeholders.
+ Make notes of system level changes (like changing font sizes) to be incorporated into a larger, usability improvement directive
Modular Design Strategy / UX-UI Style GUide
When creating this, we wanted to set a cohesive, harmonized set of graphs so that when the developers were put in charge of making the widgets, they would follow a consistent style. Thus, we created a style guide page for graphs with explanations to developers what each graph is best suited for. These graphs were then documented with their source code attached for the most convenience to our development team.
Prototyping & Refinement
Applied paper prototyping to see if the flow was as easy as it could be. This also allowed for quick redlines to be made on any errors and if any other view controls needed to be added to each specific card.
At the end of the project, there were about 28 widgets proposed. Here are two of them. The contained information is the same as the initial reports from before this project. The widgets have visuals and more dynamic controls to manipulate the data for the end user. Unfortunately, the company decided to ditch all these ideas and change the color of the existing UI only.