Case Study
Ossis Integration
From Rejection to Waitlist:
Redesigning a Surgical Integration in 3 Weeks
My role
Senior Product Designer
Scope
Discovery, user research, workflow design, prototype design and validation.
Regulated Med-Tech | AI Software | B2B | SaaS
Regulated Med-Tech | AI Software | B2B | SaaS
COntext
Formus, a surgical planning platform, needed to integrate an external nect cut guide ordering system. The workflow had to accommodate complex permissions, timing constraints, and two very different user types: surgeons who want everything automated, and sales reps who need efficiency and bulk ordering with no repetition.
Problem
The integration had been planned internally for months. Three weeks from go-live, I was brought in. The requirements and user flows existed. The wireframes did not.
Key contribution
Reading the requirements cold, I had immediate concerns about where the ordering step sat in the workflow and how much friction it created for both user types. The complexity of the permissions and timing logic had been solved technically, but the experience of moving through it hadn't been interrogated.
I wireframed and prototyped the flow based on the existing requirements, then walked four key users through it. Their feedback confirmed my instinct -- the ordering process was too clunky. I also surfaced misalignments between Ossis safety requirements and Formus assumptions about workflow.I redesigned the flow to be significantly simpler while maintaining every core requirement
I wireframed and prototyped the flow based on the existing requirements, then walked four key users through it. Their feedback confirmed my instinct -- the ordering process was too clunky. I also surfaced misalignments between Ossis safety requirements and Formus assumptions about workflow.I redesigned the flow to be significantly simpler while maintaining every core requirement
Key Impact
User sentiment shifted from "I wouldn't use this, it's too annoying" to "I want this for every case." The integration went live and generated more orders than Ossis could fulfil, a supply problem caused by demand that hadn't been anticipated.
The technical complexity had been solved. The human complexity hadn't. Three weeks out, with fresh eyes, that gap was visible. It just needed someone to look.
The technical complexity had been solved. The human complexity hadn't. Three weeks out, with fresh eyes, that gap was visible. It just needed someone to look.
my Impact as a Product Designer
Brought in three weeks before go-live, I identified critical friction in a workflow that had been planned for months and gone unquestioned.
By prototyping the flow and testing it with four key users, I confirmed my initial instinct, simplified the experience significantly, and surfaced misalignments between third-party safety requirements and internal assumptions.
The result was a complete shift in user sentiment, from outright rejection to enthusiastic adoption, and an integration that exceeded demand projections to the point where supply couldn't keep up.
The technical problem had been solved. I solved the human one.
By prototyping the flow and testing it with four key users, I confirmed my initial instinct, simplified the experience significantly, and surfaced misalignments between third-party safety requirements and internal assumptions.
The result was a complete shift in user sentiment, from outright rejection to enthusiastic adoption, and an integration that exceeded demand projections to the point where supply couldn't keep up.
The technical problem had been solved. I solved the human one.
3
Redesigned a months-long planned integration in 3 weeks without compromising a single core requirement
4
Identified critical workflow flaws through interviews with just 4 key users, 3 weeks before go-live
120
User adoption exceeded projections by 120%, generating more demand than Ossis could fulfil.
Constrains & trade-offs
The constraints on this project were significant. Access to surgeons and sales reps was limited, so every user touchpoint had to count.
Regulatory requirements for Australia and the US added complexity around patient data, particularly anything involving email notifications, which shaped what was technically permissible versus what users actually wanted.
Two of my proposed solutions had to be redesigned due to compliance requirements. A bulk ordering feature for sales reps on the dashboard would have saved considerable time but couldn't be placed there due to patient safety regulations. It was moved to the case settings page instead.
A proposed "always order guide" toggle in surgeon settings, which sales reps strongly wanted, was ruled out because regulations required surgeons to manually approve every guide.
The most significant trade-off was one I flagged rather than designed around. Ossis wanted Formus to own the notification workflow, alerting users when their neck cut guides were ready. But Formus had no visibility into or control over the Ossis production timeline. Taking on that responsibility would have meant absorbing reputational risk for delays that were entirely outside our control, with no commercial upside. I worked with both teams to establish that once a guide was ordered, all user communication became Ossis's responsibility. This protected Formus from a liability no one else had identified.
Regulatory requirements for Australia and the US added complexity around patient data, particularly anything involving email notifications, which shaped what was technically permissible versus what users actually wanted.
Two of my proposed solutions had to be redesigned due to compliance requirements. A bulk ordering feature for sales reps on the dashboard would have saved considerable time but couldn't be placed there due to patient safety regulations. It was moved to the case settings page instead.
A proposed "always order guide" toggle in surgeon settings, which sales reps strongly wanted, was ruled out because regulations required surgeons to manually approve every guide.
The most significant trade-off was one I flagged rather than designed around. Ossis wanted Formus to own the notification workflow, alerting users when their neck cut guides were ready. But Formus had no visibility into or control over the Ossis production timeline. Taking on that responsibility would have meant absorbing reputational risk for delays that were entirely outside our control, with no commercial upside. I worked with both teams to establish that once a guide was ordered, all user communication became Ossis's responsibility. This protected Formus from a liability no one else had identified.
Commercial OutcomeS
The integration launched to adoption that significantly exceeded expectations. With approximately 400 surgeons each averaging around 30 cases per month, the volume of neck cut guide orders created a four-week backlog at Ossis, a supply constraint caused entirely by demand the integration had unlocked.
At an estimated $50 per case, the commercial scale of that uptake was substantial.
Beyond the numbers, the integration strengthened the commercial relationship between Formus and Ossis. The two companies continue to collaborate on refining the workflow, and more automated features are planned. A sign that the foundation built through this project has become a platform for ongoing partnership rather than a one-off delivery.
At an estimated $50 per case, the commercial scale of that uptake was substantial.
Beyond the numbers, the integration strengthened the commercial relationship between Formus and Ossis. The two companies continue to collaborate on refining the workflow, and more automated features are planned. A sign that the foundation built through this project has become a platform for ongoing partnership rather than a one-off delivery.
Key Learnings & Outcomes
The clearest lesson from this project was the cost of involving design late. Neither Formus nor Ossis had been talking directly to surgeons or sales reps during the planning phase, which meant key user needs around notifications, bulk ordering, and approval workflows were either missed or misunderstood.
Earlier design involvement would have surfaced these issues in discovery, not three weeks before go-live.
The project also shifted something at a leadership level. Before this integration, the design role at Formus was largely understood by some as execution, coming in at the end to "draw up" what had already been decided.
The Ossis project made visible what a product designer actually contributes: catching what others miss, asking the questions no one else is asking, and protecting the business from risks it didn't know it was taking.
That shift in understanding was, in some ways, as valuable as the integration itself.
Earlier design involvement would have surfaced these issues in discovery, not three weeks before go-live.
The project also shifted something at a leadership level. Before this integration, the design role at Formus was largely understood by some as execution, coming in at the end to "draw up" what had already been decided.
The Ossis project made visible what a product designer actually contributes: catching what others miss, asking the questions no one else is asking, and protecting the business from risks it didn't know it was taking.
That shift in understanding was, in some ways, as valuable as the integration itself.
The Ossis integration was a single, high-stakes workflow problem solved under pressure. But it pointed to something bigger, a product organisation where user needs weren't consistently surfacing early enough to shape decisions. What followed was two years of building the infrastructure to change that. If you would like to learn more about my journey to towards that goal, click here to view my Formus case study on the Formus User Needs Visiblity problem.
.gif)
.png)
