Saving 8-12 months of dev time and the careers of surgeons with limited research resources.

A medical startup developing a surgical robot was planning on developing a companion app that would let surgeons track their performance and analytics.

Using a rare opportunity to interview a very senior surgeon, I prevented the startup from wasting limited time, resources, and labour on developing a high-risk high-uncertainty feature that might have undermined our very mission.

Key Achievements

Facilitated user research that uncovered product critical insights missed by competitors and product leadership.

Safeguarded against the development of an undesirable feature with significant ethical concerns, saving the company 8-12 months and diversion of human resources within an already resource-constrained startup environment.

Moved nimbly and quickly a time-limited research opportunity was taken full advantage of.

Contributions
User research
Usability testing
Wireframing
UI prototyping
Tools
Figma
Figjam
Adobe Photoshop
Team
Shoji Ushiyama, Product & UX Designer
Joseph Kabin Kim, Product Lead

Project Background

Revolve Surgical's goal was to develop and release a more affordable, general-purpose robotic surgical device in the face of expensive, complex, specialised competitors.

To take on entrenched competition, the Revolve Surgical System (RSS) was to be positioned as the medical robotic device "for the other 90% of surgery cases".

While hospitals may only have a couple higher-end competitor systems reserved for the most sensitive of cases, every other operating theatre could be equipped with the far more affordable, simpler, and flexible-use RSS.

My role within the organisation was to establish an aligning product design vision for the RSS, and to refine said vision into a more grounded design spec in time for the startup going public that summer.

The Plan
The product lead wished to remove our competitors' differentiation by providing a mobile dashboard to offer analytics and telemetry.
We'd perform additional user research to build out feature requirements.

As the designer providing strategic vision to the RSS' development, I offered the lead product owner assistance in facilitating the research.

Before going through detailed product planning and lengthy regulatory approval process, I mocked up a few wireframes to validate the concept with potential users.

Research Preparation

The plan was to invite our senior surgeon for a combination of user interviews and concept tests to reveal how they might use Revolve 360.

I quickly mocked up a set of wireframe concepts using a combination of Figma and Adobe Photoshop, alongside some older concepts that were prepared earlier. I'd use these as a visual aid and help align our participant with the product concept.

Despite a false start stemming from a last-minute reschedule from our participant, we regrouped and were ready to conduct the interview the following week.

We were ready for a simple user interview...

...but, from experience, nothing is ever that simple when it comes to user research.

The Pivot

While we were initially confident in the value of personal telemetry logging and performance analytics, our senior surgeon interviewee turned that attitude completely on its head.

Insight 1
They couldn't see much value in viewing personal analytics, and believed most of their colleagues would agree.

The only real benefits they could identify were as a training aid for new practitioners, and providing comfort & ergonomic recommendations tailored for each surgeon. Both could be opportunities, but still were fairly niche use cases with relatively limited impact.

”How many surgeons are going to be using this data? Probably a pretty low number.

— Surgeon interviewee commentary

”There might be some use if I could use this data to show that the robotic arm helps me be more efficient. But for the average surgeon...I'm not sure if this is going to be a significant value-add for Revolve. That's my general impression.

— Surgeon interviewee commentary

Insight 2
They worried that collecting this data would only incentivise hospitals to reward physicians on speed, over safety or quality.

If all this data was being collected, including analytics about procedure time per-surgeon, could hospital administration begin rewarding physicians that complete more jobs faster, or punish those who were slower?

This was a surprising but significant ethical red flag for us—our goal was to raise the bar in every operating room by alleviating physical stress for surgeons on long operations. What if our product, in a rush to match our competitors, intentionally worsened medical outcomes when adopted at scale? It was a chilling thought.

”What a lot of companies get at now is that they collect this data so that it can be used by the hospital team. Physicians can be graded based on metrics like time...It's making a lot of people nervous.

— Surgeon interviewee commentary

”You're not the first company to ask, and it seems to be the way things are going...but is that good, if Big Brother's always on my shoulder and I can get hired, paid, or fired based on this data?”

— Surgeon interviewee commentary

It's about listening

This moment was a crucial reminder of the invaluable role user research takes in ensuring we made thoughtful product decisions.

Thanks to a single user interview, we avoided not just spending our time and energy building out an unnecessary product feature, but ensuring we wouldn't create something that did more harm than good. It underscores how essential it is to validate assumptions through direct user feedback before committing to development.

The surgeon interviewee's concerns about data collection potentially incentivising speed over safety revealed a blind spot in our thinking that could've had serious ethical implications. Without this critical insight, we might have proceeded with a feature that undermined the very medical outcomes we aimed to improve.

Thanks for checking out my stories.
Let's do excellent work together.