problem

The electronic medical record (EMR) patient chart layout is designed for smaller screens, and does not take advantage of modern day usability advances like hover to discover and popup shortcuts. Delivering the appropriate information to each provider at the right time is important to improve efficiency in providers. The Storyline project aims to bring the most important information for each provider to the forefront of the patient chart, and quickly tell the patient story to each user.

role

I served as the User Experience Coordinator on this project. My responsibilities included designing and carrying out large scale usability studies as well as coordinating usability testing efforts for individual modules and applications. I worked alongside user experience Designers, developers, project managers, and software testers to complete this project.

summary

This project redesigned the patient chart. The biggest change as part of this redesign was moving the patient header from the top of the screen to the left side. This new, left-sided, header is called the Storyline. The Storyline is designed to be user and module specific, so there are many different Storylines developed for each module. Another big change as part of this redesign was the relocation of activity tabs. These tabs were moved and redesigned to be more in line with modern standards.

background research

I conducted background research to help guide the big picture decisions about the new patient chart layout. I conducted an online literature review to find existing research on software layouts. I referenced many of the Neilson Norman Group articles to present key layout features that were tried and true. These include things like consistent navigation, lists presented vertically, F pattern of reading, and appropriate widescreen content layout. These principles were used to develop a style guide, which would aide individual modules in creating their Storylines.

what we learned

From the initial literature review, I learned a lot about typical website layout. Because the users of the EMR are also users of other websites, it makes sense to use many of those principles here to keep the experience consistent for our users.

style guide creation

As mentioned above, there are many individual Storylines. A style guide was created to give some overarching guidelines so that each individual module could develop their Storylines with a cohesive look and seamless experience for users. This style guide included information about the general layout so that users would know where to find certain pieces of information regardless of the module they were using. The guide also included stylistic guidelines so that each Storyline would include the same standard fonts, spacing, and overall layout.

formative usbility testing

Formative usability testing was the first round of testing done for this project. The goal was to determine what the best overall layout for the Storyline and activity tabs. This was task-based testing done on high fidelity prototypes. The participants were users of the current system and the tasks were written to include typical tasks the user completes using the software on a daily basis. We gathered both qualitative and quantitative data from this testing. The results of this testing, combined with the style guide and existing research, were used to design the first iteration of the Storyline.

what we learned

Formative usability testing gave the team a direction to go in. We learned which pieces of content were most important for each module to use as a starting point for individual module testing. We learned what would be most useful in terms of layout, and to minimize scrolling and screen jumps as much as possible. We learned that everyone had their own way of customizing and maximizing their existing tabs, so it was important to keep those customizable. We figured out general size estimates and determined strong contenders for fonts, colors, and icons. We learned that hover capabilities were a win for users.

my role

My role in this formative usability testing was to work with one partner to write, setup, and coordinate the studies. The two of us were also responsible for analyzing the results and creating a report.

Individual module testing

Once the general format was decided on, individual modules started doing their own testing to influence the first iteration of their designs. Applications ran usability studies with their users to determine what specific information would be useful in the Storyline, and what sort of quick actions might help improve efficiency. Applications accomplished this through focus groups, user interviews, card sorts, personas, and surveys. The results of these studies were used to determine the content included in the Storylines. After these initial studies, teams began running more in depth, task-based, studies. These studies informed Individual applications continued to run studies and iterate based on findings for over a year. The style guide was updated from time to time as results came in that necessitated updates.

what we learned

This testing yielded many changes and different iterations. The content was re-worked and rearranged. Quick actions were added or improved. The overall UI was given a facelift and then re-tested. New Storylines were created and tested based on needs that emerged from results of these studies. This testing and iteration continued until each module felt that each of their users had a useful Storyline, and had the results to back up that claim.

my role

As the User Experience Coordinator my role during this initial individual testing push was to oversee individual applications usability testing. I advised individual teams of the studies to run, and helped write and facilitate studies as needed. I assisted with writing and conducting studies when needed and served as a point of contact for individual team usability representatives. Additionally, I was responsible for reviewing results to determine whether an application had conducted sufficient testing and incorporated results appropriately.

longitudinal usability study

As individual applications were continually running usability studies a few trends emerged. We found that one of the biggest concerns was how quickly users would be able to adapt to this massive change. In healthcare, providers cannot afford to be bogged down by unfamiliar software, so this was a big concern for us. To determine how much of an issue this change might be, and to pinpoint pieces that were the biggest concern for usability, I crafted a longitudinal usability study. This study was task-based, and included tasks that providers typical perform using the software on a daily basis. This was an AB study, so that the trends between the existing layout and new layout could be compared against each other. The study was run 4 times over the course of 2 months with each participant. Throughout the 2 month study, the tasks remained the same, but the patients the tasks were being performed on changed. This was to mimic the real world where providers often complete the same general tasks with each of their patients. The study was written such that qualitative and quantitative data could be gathered. The participants were asked to complete the tasks, and facilitators recorded answered to questions about task completion. The participants recorded their confidence in the task each time as well. This information provided many data points which I was able to study the trends in.

what we learned

From the longitudinal study we learned that the new layout was learnable, and that users, in general, got used to the change. Users started to see even more value in the new feature after several times using it. We did lean that the change management aspect was worrisome, though. To combat this, the team came up with an on-boarding activity to be used when this is first rolled out. It walks users through the new features so they are oriented and able to take advantage of all the new features.

my role

For this longitudinal study, I look the reins. I wrote the studies, coordinated the testing, facilitated many of the studies, and analyzed the results.

eye-tracking study

Another piece of feedback the team kept getting was concern over providers who bounce from module to module. Although the style guide provided guidelines to keep all Storyline’s cohesive, there was still concern about recall and muscle memory for some of these providers. To study this an eye-tracking study was conducted. The study used a Tobii eye-tracking machine to measure the participant’s gaze. This study was task-based, and the tasks walked the users through a typical scenario where they were logging into multiple workspaces in the same day. The goal of the study was to determine where the users eyes landed when looking for pieces of information on the screen that had shifted a bit due to the context. We wanted to determine whether or not these shifts were enough to cause confusion and increase the time on task.

what we learned

This study showed there was not a significant variance in eye gaze when users were looking at the screens in different contexts. The time on task was not significantly affected by the changing context, either. These results validated the design decisions, and no changes were made as a result.

my role

My role in this study was to write and construct the study. This required research into which tasks would be appropriate, and what a typical scenario that involves switching contexts would be. I was also responsible for writing the tasks in a way that would generate useful results.

where are we now?

The project is being released and rolled out in the February 2019 release. Usability results at this point have suggested no other changes, and this project is ready to be used in the wild! As is to be expected, I am sure feedback will roll in as the first few groups begin using this new layout, and the project will undoubtedly go through some tweaks and updates until it is just right!

constraints

specific user type and setup

Because this project delivered user-specific content, the users needed for testing were very specific. Often times it was difficult to find the exact users needed, and sometimes the tasks were not precisely appropriate for every user. Additionally, every organization does things differently, and creating a generalized study meant some things were unfamiliar for some participants.

large number of participants

To get statistical significance with these studies, we required quite a few participants. Because there were so many different Storylines that needed to be tested with specific user types, we ended up needing a lot of studies run. This was often tough to do in the intended time frame.

conflicting priorities

The team I worked on was large and multidisciplinary. There were many conflicting priorities at times as completing the project was top of mind for many. Finding the balance between the right about of UX testing and the right amount of time spent on testing was difficult.