Surgery · HealthTech · Web · AR
NDA
A platform for surgical practice and education
It started as one tool that turned CT and MRI scans into 3D models. I stayed with it as it grew into a platform for surgeons, educators and medical students, bought by hospitals and universities.
- Role
- Senior Product Designer, design system owner
- Team
- Stakeholder (former surgeon), PM, BA, developers, QA
- Platforms
- Web, HoloLens (AR)
- Users
- Surgeons, medical students, educators
Overview
Challenge. Surgeons usually read CT and MRI as stacks of flat 2D slices. And the scans and videos from each operation were hard to share with colleagues and students.
My role. I designed the 3D viewer, the AR app, video, collaboration and education modules, doing my own research and testing. I also built the design system from scratch.
Outcome. Separate tools became one platform with six modules. Hospitals bought it, and universities bought the education tools.
How the product grew
It grew one module at a time, roughly in this order:
3D from scans. Patient records with CT and MRI upload, converted into 3D models, and a viewer for exploring anatomy and spotting pathologies.
AR in the operating room. The same models in HoloLens, for use before, during and after surgery.
One platform. Analytics on operations and patients, and procedure videos you could upload, annotate and edit. 3D and AR moved into the same product.
Collaboration. Hospital departments could share videos and review each other’s work.
Knowledge base. A case library for each specialist, and later Atlas, which surgeons share with medical students by link.
Education. A quiz builder where educators make tests and exams from platform content.
Turning separate tools into one product
This was the hardest part of the project. Each module had started as a separate tool with its own logic, and surgeons, educators and students needed different things from the same product. With every new module, it got easier for people to get lost.
What I did
- Designed one navigation structure that every module had to fit into.
- Built onboarding for each role: a short product tour and contextual hints, different for surgeons, educators and students.
- Tested navigation and onboarding with our panel of surgeons before releases.
Later modules, like collaboration, Atlas and the quizzes, went into the same structure.
Safety in the viewer and in AR
In surgery, opening the wrong patient or mixing up left and right is a clinical risk. And in the operating room, surgeons’ hands and attention are already busy.
Avoiding mistakes
- Patient name, ID and scan date always visible, both in the viewer and in AR.
- Left/right orientation markers on every 3D model.
- A confirmation step before sharing, and anonymized data in anything that reaches students through Atlas.
- Every sharing flow followed medical privacy rules: what can be shared, with whom and in what form.
Keeping AR simple
- I didn’t port the web tools into the headset. Only the key actions made it in.
- Large targets based on Microsoft’s mixed reality guidelines, menus no more than two levels deep, and a few big toggles for anatomical structures.
- Preset views in one tap, voice commands for when hands are busy, a reset for models that drift away, and high-contrast UI for operating room lighting.
- Replaced some native HoloLens interactions with our own and added onboarding inside the headset.
We learned the most from real pre-operative sessions. Surgeons used the headset, and I went through the in-headset recordings to see where gestures, layout and flow broke down, then reworked those parts.
Teaching with real cases
Over time, surgeons collected a lot of cases, videos and 3D models on the platform. That made it useful for teaching, and education became a new market for the product.
What I designed
- Annotation and editing for procedure videos. These recordings were the starting point for feedback and teaching.
- Atlas, a knowledge base surgeons share with students by link.
- A quiz builder for tests and exams, where questions can include 3D models and procedure videos from the platform.
Universities bought the education tools. Hospitals asked for custom versions of the platform, and we designed them based on their feedback.
Research and validation
Having a former surgeon as our stakeholder helped a lot, but we didn’t want to build on one person’s opinion.
Daily input. The stakeholder worked with us every day.
A panel of surgeons. Before releases, I tested Figma prototypes with 6 surgeons, using scenario-based tasks, surveys and interviews.
Ongoing research. Every release tested a few hypotheses. Between releases, I kept doing user research and competitor analysis with the stakeholder and PM.
Disagreements. When we disagreed, we went back to the test results.
Into the backlog. I turned research and feedback from the panel and hospitals into requirements, prioritized releases with the stakeholder and PM, and wrote user stories and acceptance criteria with the BA.
Design system
I built the design system from scratch and looked after it. The web platform, the 3D viewer and the AR app all used it.
- Semantic tokens, which also gave us a dark theme. In medical imaging, a dark UI is the norm.
- Atlas and the quiz builder were put together mostly from existing components.
- Components were structured the same way as in code. Developers had fewer questions.
- Documentation for components and usage, updated as Figma added new features.
Metrics
What changed after the redesign, and the decision behind each number.
+15 pp
Users active in 2+ modules per month
One navigation shared by every module
+9 tasks
Navigation tasks completed without help
Two prototype iterations
−39%
UI bugs per release
Design system, components mirrored in code
pp: percentage points. Analytics figures compare the quarter before and after release; usability figures come from a moderated study with the same surgeon panel.
Looking back
If I started again, I’d set up the design system before the first module and treat the product as a platform from day one.