Patient Scheduling Portal - Rescheduling Indicator & Process Improvement

Summary

I was the Interaction and UX Designer for a web-based patient scheduling portal on Salesforce Lightning. This portal is mainly used by healthcare providers (HCPs) who are treating cancer patients to schedule them for cell therapy treatments. The portal allows them to see a patient’s journey from end-to-end: from when they are scheduled for an appointment, when the drug product is being created and shipped, and when the patient is finally administered the product.

Goal

For this iteration of the web app update, there was a need to find a way to indicate when a user makes a change to an appointment on the portal. We needed to continue to display the old scheduling information while also showing the new date and time the user has chosen on the calendar simultaneously. We also need to show a confirmation screen for users to check what they modified before they submit the new date and time.

Methodology

  • Analyze current screens and understand the flow of scheduling for product delivery

  • Evaluate for pain points where users may miss or forget information when in the process of rescheduling

  • Collaborate with product owners to iterate on mockups

  • Review Salesforce Lightning Design System to align designs on, as well as the project design library

Tools
Sketch, InVision, UXPin

Role
Interaction Designer, UI/UX Designer

Timeline
August 2023-January 2024

Current State Analysis & Evaluation

A modification flow did not exist for rescheduling product delivery. Users would need to contact Patient Scheduling directly via phone to reschedule; this caused delays as users would be put on hold for a while before reaching a scheduling representative to make changes to the delivery. The users are also HCPs who had many patients to attend to so often times waiting on the phone would take up time from working with other patients. This pain point was expressed to business representatives who frequently work with hospitals and collect feedback from HCPs.

Step 1: Viewing the calendar

There was already an existing flow for scheduling product delivery, but not for rescheduling. When scheduling, the user is taken to a calendar with prepopulated information for the site the drug is being delivered to. To keep the portal consistent, we wanted to keep a similar feel for the rescheduling flow.

Step 2: Selecting from the calendar

When a user selects a date and goes on to select a time for product delivery on the calendar, whatever they selected is highlighted. Once the user is happy with their selection, they can click ‘Continue’ to move onto the next step.

Step 3: Submitting the request for delivery

After clicking ‘Continue’, the user is taken to a Submit screen to review the information they selected as well as the site delivery information. The user has the option to go back to make changes on the previous screen or click ‘Request Delivery’ if all looks good.

In this old flow, the update needed to be made at the decision point “Is a modification needed to drug delivery?” and update the “Call Cell Therapy 360” process so that modifications are made within the portal. The team determined that users should be able to modify the delivery site, delivery address, delivery contact, and the delivery date and time. These all needed to be part of the new modification flow.

Research Results

I held meetings with the business team who worked closely with our on-site hospital facilitators to get the information I needed to design the mockups. I also did secondary research on patient-facing portals and any cell therapy-related apps on the market. The results of the research phase yielded 3 top feedback points I kept in mind while designing the mockups:

Ideating and Solutioning

Designing to show current + new selections

The first option was to include two new fields below the calendar. The first field displays the current product delivery date and time. Before the user selects a new date and time on the calendar, there is a second field displayed next to the first one, but is empty. Once the user selects a new date and a new time, the selection is displayed in the second field.

Option 1

Pros/Cons

  • The top of the calendar is too busy

  • The new section on the calendar appears too abruptly and doesn’t really fit the formatting of the current date format

The second option was to include two new fields at the top of the screen, altogether with the already existing fields that are displayed there. Similar to option one, there are two fields: one to display current date and time, and the other to display the newly selected date and time.

Option 2

Pros/Cons

  • Confusing having an empty field without a value (users might think they should already have something there

  • Placement helps user to immediately see the change they made since they select date and time directly on the calendar

The third option was to include one new field that displays the current date and time up at the top with the existing fields. After the user selects a new date and time, a new section will appear on the calendar and display the newly selected date and time.

Option 3

Pros/Cons

  • The top of the calendar is too busy

  • At the same time, there is argument that keeping all fields up top keeps a consistent design

Designing to indicate change - what comes after choosing the new date and time?

Option 1

Once the user gets to the submission screen, any changes made on the previous screen are displayed with a strikethrough in the value and the new value displayed below the old values.

Pros/Cons

  • The screen looks too busy

  • The screen is overloaded with text

Option 2

If a field was edited on the previous screen, the submission screen displays a modified badge next to the edited fields that hold the new values.

Pros/Cons

  • Immediately eye-catching

  • The badge is large enough for the user to immediately know a modification was made

  • Uses a new symbol that we have yet to use across the portal so will be a new experience for users

  • Minimizes task uplift by leveraging an existing asset of the Salesforce Lightning Design Library and the Cell Therapy 360 Portal Design Library

Option 3

Similar to Option 2, if a field was edited on the previous screen the submission screen displays a warning symbol next to the edited fields that hold new values.

Pros/Cons

  • Confusing with the red warning symbol of the design system in a different area of the portal (red warning symbol indicates an issue with the form)

  • Too many helper texts at the bottom of the screen

  • Simple symbol that immediately lets users know there’s something different

Final Product

For the Select Date & Time step, the business team went with Option 1, where both dates and times are displayed at the bottom of the calendar. For the Submit step, they decided on Option 2 with the yellow modification badges.

The new feature adds a whole new modification process to the current product delivery flow. Users now have the option to directly modify and reschedule for their patient in the portal as opposed to having to call Cell Therapy 360 to potentially modify a patient’s delivery information. Similar to the scheduling flow, they are able to update pre-populated information, select a new date, and select a new time.

The first obstacle in this project was always being unable to test or interview users, as our team never had that access to users. The only time we knew something had to be fixed or corrected was when the system had already gone live with new features and got feedback a few weeks later from our business team that there was something users did not like.

There was also never really any time for thorough ideating, brainstorming, or sketching; mockups needed to be high-fidelity to immediately present to business stakeholders to turn decisions around quicker. This wasn’t too hard to do as we already had a pretty well-designed system and assets readily available to create new screens but there wasn’t enough time to discuss and whiteboard as much as I wanted.

The project overall was always on a time crunch - there was always a change that needed to be made, front-end or back-end, and each release reached capacity or went over. The user experience was not prioritized as much as it should have been, but the team was getting to the stage where we needed to make the time to do so.

In a way, presenting all the options upfront was a process of iterative design with my team. Because we had to quickly turn things around and get things into development, we had to churn out more ideas and discuss all details within 2-3 meetings before deciding on the final design.

Challenges

  • Get creative when you don’t have direct access to the user base - what questions can be asked to the business that can aid this process? What metrics can be measured post-release?

  • Have earlier conversations about features, even if it’s not slotted for the current release. Ask questions about the future state.

  • Start a process if one doesn’t exist: I started to create a process while at BMS to include UI/UX work further up the workstream so that we had more time to work with the business team and get more perspective/feedback from the end users. While this was not as fleshed out when I departed, it started meaningful conversations and even some talk about hiring consultants to do this work!

Lessons Learned

Next
Next

Goodreads - Visualizing Reading Habits