Flexibook Case Study
In 2021, an Australian development team working in the healthcare sector approached us with a request to redesign some of the existing features in their healthcare product's appointment booking platform. They named the updated booking platform "Flexibook" as a reference to the new, highly flexible workflow that the team wished to create with the new booking platform.
While the project was originally introduced as a chance to brainstorm ideas for a future release many years down the line, the request quickly changed to a full fledged redesign with the addition of three new pieces of functionality. In total, the project took roughly one year and went through countless iterations, eventually shipping to a large hospital network in Australia and New Zealand in June 2022.
I led the UX design on this project but worked closely with one other UX designer, a project manager, a product owner, and a host of developers and engineers, including a few rotating interns who helped build out some of the key features that led us to success.
The Challenge
The platform we were asked to redesign lived within a complex, feature-rich EMR system built on an old framework that did not allow any changes outside of the existing components' functionality. This constraint meant that we were not able to create any patterns or behaviors that did not already exist elsewhere in the healthcare platform.
The main challenge with the project was to find a solution that would enhance all the existing aspects of basic appointment booking while consolidating all the unique features and supporting use cases from the other booking systems, like appointment booking for surgeries or family bookings, into one unified system.
Phase 1: Booking a Standard Appointment
Since doctor's office visits can range in reason and severity, we decided to start the project by evaluating the workflow and use cases for a standard 15-30 minute check up.
We quickly learned from our stakeholders that this process is much more complex than we had initially imagined as the users performing appointment bookings could be an administrator, a call center operator, or even a clinician themself depending on the size and setting of the hospital or clinic.
When we started our walkthrough of the existing platform, we discovered that each of these users started their workflow in a different place, meaning that the steps required to simply book a 15 minute appointment would differ drastically depending on what the user's role was.
Because we knew the project called for many additional features, we decided to evaluate the existing booking platform as an administrative user. This particular user typically has access to more features than other, more specialized, users and would allow us to quickly assess a wide breadth of features.
We then narrowed our scope for phase 1 to focus primarily on the steps in the workflow that were common to all of our target users, which included:
1. Searching for an existing patient or adding a new one
2. Selecting an appointment type and hospital location
3. Finding an available time
4. Confirming the booking
Rough sketch showing flow for enter booking platform
Pain points
The biggest pain point we found when attempting to schedule a basic check up was that the order of operations for performing each of the tasks listed above was extremely unintuitive.
For example, all users had to start the booking process by manually searching for a doctor's order for an appointment, an appointment type, or a hospital location rather than searching by patient.
To further complicate the flow, the screen layout required the users to manually drag and scroll through individual panes within one workspace creating high friction and lots of room for error at every step of the booking process.
Original workflow for booking a check up appointment
Phase 1 Solution
Our initial walkthrough made it clear that there were some major issues with the platform's information architecture and general page layout. We wanted the screen to read from left to right, top to bottom but to do that required us to rethink how search and select worked.
I started by sketching out the 12 different search criteria and grouping them into meaningful categories that could serve as drop down menus in an effort to fit all searchable items and any new one's that could appear in future iterations into one left hand search pane.
We also needed our search and select flow to align with the "Patient List" flow that users in other areas of the healthcare platform frequently see. Since we couldn't change how patient search or the patient list worked, I decided to have the search categories follow a similar order to the information that automatically generates patient banners and table rows in the patient list.
Rather than start the search criteria with the patient's name, I used URN/MRN with the additional check box to filter between inpatients and outpatients as these are not only clinical requirements, but also the best methods of quickly finding a singular patient and their most current, active medical record.
Search criteria layout (left), getting to the same point via patient list entry point (right)
We spent a lot of time on the search pane because it was the main driver for the rest of the booking platform and also the most critical step to get right in order to pass clinical safety standards both in the U.S. and the other countries and territories that the product would eventually ship to, hence the inclusion of fields like national ID and age type.
We also made the decision to move the list of available appointments to the top of the screen and place the cart with the user's selected appointments at the bottom so that user's eye would fall closer to their selections while going to click the final commit button. This was a fairly simple change that saw a lot of pushback from stakeholders because it was a new paradigm for the booking platform.
To mitigate the pushback, we put together a clickable prototype and shared it with stakeholders from some of the regions we worked with. After a quick demo, we found that a majority of the stakeholders agreed that the layout was acceptable as there are usually more available appointments than selected appointments.
Once we gained final approval from our stakeholders and the rest of the team, our developers began implementing the search pane and list layouts.
New workflow for booking a check up appointment
Phase 2: Booking Non-Standard Appointments
For phase 2, we started thinking about how to handle more complicated appointment bookings such as recurring appointments for patients with chronic conditions and family bookings where there may be more than one patient under a single appointment slot.
We spent a lot of time, trying out different buttons, drop downs, or toggle options to make space for these complex scenarios within the same screen that we created for a single appointment but weren't able to find an elegant solution to the problem.
We looked at a lot of other apps and websites to try to draw inspiration but nothing quite matched what we were looking for. Our use cases were more complex, our information was more dense, and our screens needed to support navigation entirely by keyboard.
I started exploring examples of places in the built environment where we tend to store many different things that are used for roughly the same purpose in one place. I found kitchens to be the perfect analogy and used the cabinet model to help think about the problem.
I created the icon side bar to function as site navigation between different kinds of booking. Using this style of navigation meant users coming into the platform from anywhere could instantly see what kind of booking they're performing while easily navigating between different kinds of booking.
We found that users often landed on the booking page for the last booking they performed. In the case of call center operators, every booking could be different since the call centers often handled bookings for larger hospital networks with 100+ clinics and hospitals.
We needed a way for our users to launch the platform and quickly move to a different booking page if their current appointment request differed from the previous one.
In order to mitigate the inevitable pushback from stakeholders, I invited a few coworkers who had recently completed a project on the same product suite that used a similar side bar navigation. The group I invited was able to help streamline the conversation and decision making process by explaining their technical implementation for the components and design justifications during their own process. They also offered to help us implement our own sidebar by reusing their base component.
After clearing the feature with our stakeholders and developers, we were able to start tackling the details behind each booking.
Since we spent a great deal of phase 1 trying to make the standard booking process as flexible as possible, we were able to quickly adjust the search pane for each booking type to support the various differences in search criteria and selection options. We then sent off our design for phase 2 to our developers who worked on porting over the older booking platforms to the new one and consolidating all of them into one unified product, accessible via the icon sidebar.
Phase 3: Building Out Additional Features
Phase 3 saw the inclusion of new sorting and viewing options on the platform. We added tabs above the list of available appointments to allow users to effectively filter their search results by using three basic criteria: Care provider, location, and appointment type/service.
These filters were implemented to improve an administrator or call operator's ability to quickly narrow down the patient's options as the tabs are persistent and automatically generated according to appointment availability and specific search criteria.
If a patient wants to schedule a cardiology exam with a specific doctor but that doctor regularly switches clinics throughout the week to accommodate other types of appointments and patients, the call center operator can simply add the doctor to their search criteria then click on the cardiology appointment tab to get a filtered list of that doctor's cardiology availability. If the patient suddenly decides that they're open to seeing any doctor, the operator can simply remove the original doctor from the search by clicking the "x" on the chip that was created when they initially added the doctor and the list of available appointments will automatically repopulate to show all cardiology doctors while the list of selected appointments will remain consistent.
We found this feature particularly useful in situations where doctors or patients want to book more than one appointment for the same service, such as booking two different dates for a follow up visit that will occur six months away from the current date. Patients will often reserve multiple time blocks for appointments that are time sensitive but fill up quickly in order to avoid having to set up a new time later on. Many hospitals also allow this as it makes it easier to ensure that the patient shows up when they need to.
We also added two more places where the user may add a patient, one at the top of the screen inside the patient banner and another as an icon in each of the rows for selected appointments. This way, the user could add an appointment to a patient or add a patient to selected appointments. Since the order no longer mattered, users coming from all entry points could make changes to patients and appointments at the same stage. If the user messed up an appointment, they could easily remove a patient and add a new one without having to exit the booking platform entirely.
Phase 4: A Patient-Centric View
During early ideation, the other designer and I wanted to implement some sort of calendar view because it felt more intuitive to us. This idea never materialized in the earlier phases because we found it too slow for the non-patient users who had to book hundreds of appointments a day. However, our stakeholders eventually came back to us with an ask to create a patient version of the booking platform.
This patient-centric view would serve both patients and administrators at smaller hospitals where there are fewer doctors and fewer available time slots each day. The goal was to create a view that would fit inside the standard booking platform but could also translate to a read only feature on the patient's health portal. Ideally, the calendar feature would be powerful enough for an administrator to utilize all the available features in the booking platform but still visually appealing and intuitive enough for an end user to print out the calendar view and carry it with them if they wished.
We found that printing out a calendar with upcoming appointments was important for older patients and those who frequently requested a printed summary of their care plan when visiting their doctor.
Ultimately, we designed two different views, one that looked like a standard calendar and another that displayed each day in a vertical column with up to five columns per page.
Through countless iterations and many broken assumptions, we created a completely redesigned, unified booking platform. Our designs started as brainstorming sessions for a future project that wasn't guaranteed to ship, then evolved into a small summer project for interns learning the ins and outs of our healthcare products and partnerships until they eventually grew into an entirely new platform that has since been in use through a large hospital network serving parts of Australia and New Zealand.
The product has seen one update since shipping and is set to release in a few of our partner hospitals based in the Asia Pacific region in 2023.
Read more about our health platform's continuous impact in this customer success story.