Verily Life Sciences

We will not see fully automated robotic surgery in our lifetime. But we can set up the next generations to achieve it. I always think of the MedPod from Prometheus, the 2012 Alien movie, as the end goal, but calibrated for both men and women patients.

The Surgical Insights Platform along with the surgical robot is a first step in building a foundation for robotic surgery. The purpose is not only to make it easier for surgeons to navigate small incisions and to decrease a patient's healing time, but also to make surgery more accurate and accessible.

Verb Surgical is a collaboration between Google and Johnson & Johnson. During competitive analysis, we discovered that the robotic surgery has a global market of ~15M potential surgeries. Currently, Intuitive Surgical is the main competitor. The penetration rate for robotic surgery is ~3%. It also has industry growth projections ranging from $5-$14Bn in the next 10 years, growing at a range of 9% to 22% CAGR (Compound Annual Growth Rate).

This is a huge opportunity for Verb Surgical. With the Surgical Insights platform, our goal was to democratize surgery and advance the overall standard of care - empowering surgeons, anywhere, to improve their surgical skills (technique and judgement) and perform at the top of their license.

It all starts with research!

To successfully build a platform for hospital staff and surgeons, I first needed to understand our users. Teaming up with a user reseacher, we interviewed several users - mostly surgeons, but we also included hospital schedulers, operating room nurses, and medical students.

I also had the privilege to observe laproscopic and robot-assited surguries at UCSD teaching hospital with Dr. Santiago Horgan, an internationally recognized expert in robot-assisted surgery and other minimally invasive surgical techniques.

The personas were created after online polls and surveys, on-call and in-person interviews. A persona is an archetype instead of an actual living human. The real value of a user persona is to list down the goals/motivation of the people who will be using the application. Understanding the users, their motivations, their requirements helps in building user-centric products.

Personas are a tool to drive use cases, user journeys, and to build empathy. The personas were a tool to help drive design decisions, particularly in the platform organization, navigation, and design of the dashboard.

Teaming up with a user researcher, we creatd and performed a Tree Test to evaluate the Surgical Insights navigation. Participants (all surgeons) were asked to complete a series of tasks looking for items using the site structure. Tree Testing allowed us to show a menu structure in its most basic form without our participants worrying about design and layout.

After the Tree Test was complete, we analyzed the data. When looking at the results we focused on three key measures:

• Directness– the percentage of users completing the task without hesitation and getting the correct answer first time
• Success – the percentage of users that completed the task
• Time – the time it took users to complete a task

Once the data was analyzed using the three key measures, we could see clearly what worked and didn't work. The results informed our design decisions. We presented a slide deck with the findings, and made adjustments to the overall organization and site structure.

Each and every surgery is referred to as a case. We named this a case centric view. Cases are the primary driver and center of the platform. By taking this case centric approach, I was able to organize the platform based on user journeys through the pre-op, intra-op, and post-op stages of a case. This also resonated with our users since they also take a case centered approach.

After I made some assumptions based on user personas, I created user flows and screens for the Case Centric View usability study. I created an interactive prototype from the screens for use in our usability study. I worked closely with the team to align on testing goals and create a test plan. Specifically, we wanted to answer the questions:

• Can portal users easily complete core tasks in case centric view and using the navigation menu?
• What is the current experience of giving and receiving feedback in surgery?

After the study, we synthesized the data and presented our findings to the whole team. I then began making updates to the flows and screens based on the data collected.

Surgeons share other cases with other surgeons in their field. Because of HIPAA laws, patient information is sensitive and cannot be shared freely. We had to establish rules for sharing information. These were organized into three buckets: owner and immediate care team view, inside hospital view, and outside hospital view.

Once we established the three different audiences, we determined what information they could access. This information then informed the information shown or not shown on the case details page, a well as how a user shared the information.

The surgical robot collects data. The surgical platform had to present that data for humans to comprehend and take action on it. The first step was to understand the users who would be viewing the data: surgeons. We then had to understand a surgeon's motivations in order to craft a story for the data.

Data is basically just a bunch of numbers. The numbers we were getting was a result of robot data. Those numbers do not mean much if there isn't a story. There are factors that influence a number. Users need to understand that in order to trust and take action.

To present the data, we answer the questions:
• What does the data tell us?
• What questions are we answering?
• What story can be formed with these questions?

We then can provide context for a number. We help users not only know the numbers, but also understand their context and be able to take actions from them. Users naturally want to understand if the value is normal, high/low, good/bad. Context is provided using comparisons, changes over time, and related content.

After confirming that providing data to users wouold be both valuable and motivating, I started researching how to build it. Working with the engineers and clinicians, we established what were the most important data and benchmarks to display. The dashboard to the surgical platform became a huge part of collecting and dispaying data and performance, while also being a centerpiece for feeding the machine learning.

I explored different ways of displaying data that was easily and quickly digestable to a user, while givig them the option to dive into the data further. I also began to utilize Google Data Studio. Google Data Studio is a dashboard and reporting tool that is easy to use, customize, and share. It allowed us to transform the robot data data into appealing and informative reports for our users.

In regards to machine learning, we were collecting all videos from the robot during procedures, but needed a scalable way to annotate the procedure videos to teach the computer to identify procedure steps. This is where the idea of bookmarking plays an important role.

In order to apply machine learning to robotic surgery, two things are needed: 1. lots and lots of data 2. identification or categorization of that data. We were getting a lot of data from the robot but needed a way to identify steps in a procedure. We asked the surgeons to provide that identification. Once a video was uploaded to the Surgical Portal, it had blank bookmarks that prompted the surgeon to view their video and drag and add bookmarks to identify steps in their procedure. It was time consuming for a surgeon but was needed for machine learning.

I created several user interface explorations to display the bookmarks, time stamps, and procedure steps. The interface also needed to show users that data is incomplete and needed to be added or edited.

Since robotic surgery is the future, many surgeons and medical students were learning how to perform robotic surgery through university programs. Working with Verb Surgical, we built a training section in the platform so those learning robotic surgery could go through their training, test themselves, and see how they performed.

Since every organization that was teaching robotic surgery had different training materials and programs that they created, we decided to allow users to upload their own documentation and training materials into the Training section of the Surgical Insights platform.

Empty states are often overlooked in UX design. Empty states are just as important to design and build for as states with content. Designing well-thought-out and useful empty state screens can help drive product engagement, delight users, and reduce churn. For the Surgical Insights platform dashboard, I utilized Google's illustation resources and pulled relevant images for each of the sections.

The images below are the Surgical Insights platform homepage with content and without content, showing the empty states.

One of the constraints of the Surgical Insights platform was using Google's standard sign in. Users signing into the platform had to have a Google email address and account. This redirected the user away from the platform over to Google's sign in pages. This was a 3-step sign in.

A user's profile page can be accessed by all users of the platform. A user can add their baisc information, as well as their cases, publications, and presentations.

To increase design and engineering consistency and velocity, a design system was created using the Material Design as a base. I collaborated with the engineering team to create a robust design system that was compatible with the code library.

The design system also made components consistent across all devices and operating systems. It allowed both design and engineering to invest and focus more on problem-solving, rather than spending lots of time creating components. There was definitely more space for exploration because design and engineering were no longer reinventing the wheel.

During user interviews and observations in the operating room, it was obvious that there needed to be a compatible and secure mobile application for the Surgical Insights Platform. Users were taking photos, sharing, and having many conversations both over SMS and telephone about cases.

The first iterations of the mobile app were optimized for mobile versions of the platform with some features stripped away for simplicity and ease of use. The mobile app also focused heavily on sharing and communication since that was what users were doing in the operating room and in the hospital.

During research, I discovered that many users' conversations shared patient information over non-secure networks (SMS and telephone conversations in public spaces). I highly recommended building a native app for security and to thoroughly meet HIPAA compliance. This was incorporated into the product roadmap and engineers began building the architecture for the Surgical Insights native mobile app.

And of course, there was testing on the robots. We needed to test that the data from the surgical robot was able to be processed in real time and displayed on the Surgical Insights Platform. Plus, the robots were super cool... and kinda like driving a car.

We started to run tests on the robot to see if the data was being uploaded to the cloud successfully. Of course, this took several tries, and it failed many times! Once we started to get the basic data from the robot, I was then able to work with the clinical engineers to decide what metrics to present and how best to present the data. This informed the Surgical Insights Dashboard and Analytics pages.