Disclaimer: The following case study is illustrative of the work completed at Northrop Grumman. They outline how the goals and job of a UX Researcher have been accomplished. The process, results, and outcomes are all based on real situations; however, the scenario, data, and application have all been adjusted to be publicly consumable.

Business to Business: Development Focused

Scenario:

Thunder LLC has been contacted by Hospital Zep with a request to update Hospital Zep’s Oncology Wing. Thunder LLC has accepted this request and has begun work on the plans for the update. The update will be known as Solution Storm Cloud. Within Solution Storm Cloud are several projects, such as Project Rain Drop, which encompasses the effort to update and create new nurse interfaces. The initial research of Project Rain Drop, identified the following critical updates;  

  • Improve nurse-to-nurse communication during shift changeover 

  • Improve situational awareness of medication stock  

  • Enable simplified scheduling of patient procedures.  

These updates would be implemented while retaining the following capabilities. 

  • View patient information pages 

  • View fellow nurse schedules 

  • A contact list separated by internal and external numbers 

These tasks for Project Rain Drop were broken up among the UX Team, with each member focusing on a specific update. However, those team members will work collaboratively to ensure consistency throughout the interfaces across Project Rain Drop.  

Solution Storm Cloud is being developed in an Agile environment where multiple stakeholders are working in tandem. This includes the software developers who will be creating the code or other UX team members who are focusing on other aspects of Project Rain Drop. In addition, there are other teams internal to Thunder LLC who have their own requirements for Solution Storm Cloud. These requirements may be based on medical regulations, security, or health and safety. Final stakeholders include Hospital Zep, who will be buying Solution Storm Cloud, and the nurses who will be using portions like Project Rain Drop in their day-to-day operations.

Case Study 2: Determining Table Interactions with Development Teams

Background:

As research continued within Project Rain Drop, collaboration between the Patient Overview Portal (see case study 1) and the Individual Patient Pages was needed. The main point of collaboration was the ability to alter a table of medications the patient was prescribed. These interactions had the potential to drive status on the Patient Overview Portal. There were three main interactions identified. The first being the ability to delete/remove medications from the table. The second being the ability to edit a medication already added to the table. The third is the ability to add a new medication to the table. 

Objective: 

The objective of this research was to determine the best design to allow users the ability to edit the table. Prior to any user research being conducted, or even writing a research plan, former research is review. This ensures there is cross functionality and consistency between the various aspects of Project Rain Drop. This initial research comprises of three major steps: review all previous research conducted, internal UX team discussion, collaborative discussion between teams. From these discussions, a decision can be made to determine if there is a need for a user session, or if there is adequate existing research that can be leveraged to drive design decisions. 

Methods: 

  • Research Review:

  • Outline a well-defined need.

  • Review existing Project Rain Drop UIs for designs that could be leveraged to meet the gap.

  • If a potential solution is found, ask the individual responsible for the design for the research associated with the design decision. 

  • Review the design research to determine if the research conducted could apply to the situation at hand. 

  • If no research is found, create a few low-fidelity solutions.

  • Internal UX Team Discussion:

  • Bring all identified designs to the meeting in addition to research found.

  • Discuss why the research conducted previously can or cannot be applied to the current research question.

  • If no applicable research was found, bring the clearly defined need, research question, and low-fidelity solutions to the team. Ask if there is any current or previous research that could fulfill the need. Additionally, discuss other people’s design needs to see if there are any similarities between the current need and a future need.

  • Collaborative Discussion Between Teams: 

  • Bring all designs to the software development team tasked with implementation. Discuss with the team the need, and how the design will be used in to fill the current gap.

  • Outline the design specifications and interactions, allowing the software team to fully understand the scope of the work.

  • Discuss any potential software limitations or pit falls that may impact the ability to implement the design.  

Results: 

  • Initial Research: 

  • The first design was an alarm queue. Within the queue the user could swipe from left to right to complete a “delete” functionality. There was also a button with a mode functionality. When pressed the user would enter the queue’s delete mode.  

  • On the medication stock page, the user could complete a click and hold function to initiate a pop-up menu. The menu had multiple functionalities specific to the user needs for that page.

  • Internal Team Discussion:

  • The swiping functionality found in the alarm queue was altered to populate icons. The user could select these icons to complete the functionalities needed on the Individual Patient Pages.  

  • The second design was altered so the pop-up menu provided the user with the functionalities associated with the Individual Patient Pages.

  • A new design utilizing a menu button used in other Project Rain Drop UIs was leveraged with the in addition to the mode functionality. When selected, the menu would provide the user to enter different modes that aligned with the needs of the Individual Patient Pages. 

  • There was concern with the alteration of the first design due to the research surround that design. The research showed the users associated the swiping action to a delete functionality. Adding the extra step of selecting icons would go against that user association. Additionally, not aligning the two workflows would create unnecessary inconsistency. 

  • The team agreed the second and third design would be good to bring to the developers. 

  • Collaborative Discussion Between Teams:

  • The software team identified a potential issue with the third design. Due to the way the table was created, there would be performance issues associated with providing the user three different mode options. 

Conclusion: 

The ability for users to interact with the table will be achieved using a pop-up menu. This was decided due to the concerns with cross display consistency and the data gathered supporting the original interaction found in the first design. Additionally, the software limitations were also a deciding factor to not continue with the third design due to the strenuous effort necessary to make the design function as described. The second design will be implemented for now to limit the time and cost associated with developing a new design. It will be tested in the future with other items to ensure there are not any unforeseen consequences in choosing this design. 

Previous
Previous

Case Study 1: End to End

Next
Next

Case Study 3: Business to Business: User Focused