Designing connected workflows for fertility care
A hospital information system I designed from scratch for a fertility clinic, built around the handoffs between doctors, counsellors, nurses, lab teams, embryologists and pharmacists. I ran the interviews, mapped the service and designed the workspaces. The platform is now used in the clinic.
Fertility care runs on a network of people: doctors, counsellors, nurses, front desk staff, laboratory teams, embryologists and pharmacists. Each completes a different part of the patient journey, but their work depends on information and actions from someone else.
My work on Leap Health OS began with understanding IVF and grew into designing a hospital information system around those dependencies. As the sole designer, I built it from scratch: I independently ran the doctor and clinic stakeholder interviews, gathered and synthesised the insights, translated the clinic's processes into workflows and interfaces, and iterated through feedback and coworker testing.
How can a shared system help each stakeholder understand the patient's context, complete their work, and hand the next step to the right person?
1. Starting with the domain, then learning the service
First: understanding IVF before we had our own clinic
My first interviews were with doctors while designing the IVF app for Motherhood and Nova IVF. At that point we did not have our own IVF clinic or an established internal process. I was learning the domain before trying to represent it in a product.
What the first doctor interviews taught me
The interviews helped me understand why IVF could not be represented as a simple series of bookings. The insights below are synthesised from my interview notes; the implications explain how that learning informed the later system work.
| What I learned from doctors | Insight | Implication for the design |
|---|---|---|
| Preparation involved lifestyle factors, conditions and investigations; notes covered AMH and AFC for ovarian reserve. | A patient’s starting point affects the journey. | Keep preparation, history and investigations accessible before representing treatment progress. |
| Notes explored stimulation, trigger timing, egg retrieval, embryo grading, fresh/frozen transfer and pregnancy testing. | Treatment steps have clinical dependencies and different information needs. | Represent stages and prerequisites while retaining the records needed for decisions at each point. |
| Doctors discussed uncertainty, anxiety, counselling and support, particularly after failed cycles. | Care continues through emotional uncertainty and unsuccessful outcomes. | Treat counselling and follow-up as part of the service, with their own documentation and actions. |
| Both partners’ involvement and emotional experiences appeared in the interviews. | Fertility care needs a couple’s context alongside individual records. | Support linked partner context while retaining each person’s identity and medical information. |
| Egg reserve, egg freezing and fresh/frozen transfer were discussed. | Patients do not all take the same path or move at the same pace. | Avoid treating the journey as one fixed sequence of appointments. |
| Notes covered situations where treatment might be cancelled or changed. | Exceptions are part of the care journey. | Consider paused or changed treatment alongside expected progression; confirm the rules with clinicians. |
| Identification practices such as MRN/RFID appeared in the notes. | Reliable identification matters across many records and procedures. | Keep patient identity visible across workspaces (these notes do not establish an RFID integration in Leap). |
IVF combines clinical sequencing, individual variation, couple-level context and ongoing emotional support. An appointment tells staff when a patient is expected; it does not explain what that patient is ready for, what information is still needed, or what support should follow.
This early research gave me the vocabulary and the questions for the next round. The first interviews established the domain; the clinic interviews established the operational workflow.
Then: understanding how our own clinic worked
Once we had our own clinic, counsellors and processes, I ran another round of interviews to understand the service in practice: who depended on whom, who passed work to whom, and which edge cases interrupted the expected flow.
The clinic research exposed a more operational problem: the patient's journey was really a chain of handoffs, and the information behind it lived in scattered places.
Counsellors coordinated across every step, while clinical decisions stayed with the doctor.
Research synthesis: the system needed to represent both the patient's treatment context and the work required to keep that journey moving.
2. Defining the problem around handoffs
The clinic interviews documented scattered information, unclear ownership, missed follow-ups and manual work. These were connected problems: when the next action or its owner was unclear, staff had to reconstruct the patient's status through messages, calls or records elsewhere.
Registration information was incomplete and manually transferred.
In the product Structure patient information and reuse details already collected.
Counsellors coordinated booking, reports, reminders and support.
In the product Give coordination work a dedicated workspace with patient context.
Clinical decisions depended on reports and subsequent visits.
In the product Support history and documents across appointments, not only the current visit.
Doctors and counsellors had different responsibilities for history.
In the product Distinguish clinical documentation from counselling notes.
Patients could miss scans, injections or appointments.
In the product Make appointment states and recovery actions visible.
Treatment could branch, pause or involve external care.
In the product Avoid assuming every patient follows one uninterrupted sequence.
Bills, packages and payment follow-ups added another dependency.
In the product Bring financial context into the service model.
Each note pairs what the clinic interviews surfaced with the design response it drove.
Translating insights into design principles
I use four principles to explain the relationship between the research and the interfaces. This is a retrospective synthesis of the work, not a claim that I ran a separate principles workshop.
These principles give a way to assess a decision: does it make the dependency clearer, support the responsible person, preserve context, or avoid asking for the same information again? The later live feedback also shows where the product still falls short of them.
3. Mapping the service before the interface
The clinic interviews described a recurring pattern, with variations by treatment and patient circumstance:
The same stakeholder recurs at different points, and each handoff carries context the next person depends on — which is why a single generic appointment list would be insufficient.
This map informed a system that needed shared patient context, role-specific actions and a record of what had happened. It also showed why a single generic appointment list would be insufficient.
4. Initial design: making treatment progress and dependencies visible
The first Figma screens explored a patient and couple workspace organised around treatment stages and tasks. The initial cluster included daily patient cards, task counts, OI/IUI/IVF filters, partner switching and treatment-stage navigation. In the IVF flow, the stages created a visible treatment structure, with future stages appearing locked and progression unavailable while required work was pending:
One example showed uploading doctor notes followed by booking tests. That relationship mattered because completing one action created the context for another stakeholder's work. The initial workspace also carried clinical notes, medical history, reports, cycle information, billing and chronological logs.
UX rationale, reconstructed from the design: visible tasks externalise dependencies that staff would otherwise hold in memory or coordinate verbally; stage navigation provides orientation, and gated progression expresses prerequisites. These are intended benefits; the supplied evidence does not establish that they reduced errors in practice.
The tradeoff in a stage-based model
Stages make a complex journey easier to understand, but clinic care can pause, repeat or branch. The notes included delayed reports, previous treatment elsewhere, donor-related paths and fresh/frozen variations. A strong stage model therefore needs ways to handle exceptions. The material establishes these needs but does not confirm how every exception was implemented.
The initial design already reached across the clinic
The treatment model was the spine, but the first screens already spanned the clinic's day-to-day work: the doctor's prescriptions and investigations, the nurse's vitals, appointment handling and the clinic's own reporting. This set up the operational breadth that the live platform would later build on.
Prescriptions and investigations were structured from the start, so detail could travel to the pharmacy and the lab.
Vitals were captured for confirmation before saving; appointment detail kept patient and visit context together with reschedule and cancel actions.
5. Iteration: testing with coworkers before launch
I shared the designs with coworkers, gathered feedback and iterated toward launch. Two things came out of that loop:
Evidence boundary: coworker testing is confirmed. The specific test tasks, participant counts, findings and the changes attributed to each finding have not yet been supplied, so this describes the iteration honestly without inventing a usability-test narrative.
6. The live platform: a shared record with operational workspaces
The screens below are faithful recreations of the live platform, rebuilt with placeholder data to protect patient privacy — layout, structure and patterns match the deployed product. They reflect an admin profile that sees all stakeholders, so they show what that account can see, not each role's own navigation or permissions.
One shared record, with a focused workspace for each role. These are the five the admin account exposes:
Shown below is what the front desk works in day to day. The consultation and counselling workspaces are visible to the admin account but not pictured here, and the effort the shared record saves isn't yet measured.
1234
Inside the profile, medical history supports record search, upload and preview; the activity log shows timestamped events and the actor behind each one.
12347. Learning from use: what the platform still misses
Stakeholders described what they rely on and where the platform still creates friction. The directions below are improvement opportunities drawn from that feedback — not delivered outcomes.
Preserve capabilities staff already depend on
Front desk feedback highlighted capabilities that are part of the existing workflow and need consideration during any redesign:
Address the gaps between system rules and clinic practice
| Current feedback | Underlying UX problem | Direction to validate |
|---|---|---|
| A medicine discount affects the whole bill; no reason can be recorded. | Financial controls do not match the scope of the decision. | Service-level adjustments with a recorded reason. |
| Slot capacity shifts the automatic time away from the agreed time. | Booking rules and scheduling practice conflict. | Clarify capacity, arrival-time communication and scheduling rules with staff. |
| No-show actions become unavailable after the slot passes. | The system prevents recording an outcome when it becomes known. | Allow appropriate retrospective status updates. |
| Staff report no way to mark a consultation done. | Completion ownership and action are unclear or unavailable. | Establish who completes the visit and where that action belongs. |
| Front desk cannot see which services were performed. | The clinical-to-billing handoff is incomplete. | Make performed services visible before charging. |
| Daily cash/UPI/card totals require Metabase. | A routine accounts task depends on another tool. | Provide reconciliation views aligned to daily work. |
| Packages live in Excel; agreed prices are hard to recover. | Financial continuity breaks across instalments. | Track package agreement, payments and outstanding balance. |
| Updates are repeated through calls, WhatsApp, sheets and the platform. | Recording information does not reliably notify the next person. | Validate explicit ownership and handoff notifications. |
These are proposed directions derived from feedback, not confirmed shipped features or completed redesign decisions.
Bring coordination and inventory work into the system
Beyond the front desk, counsellors and pharmacy described core work still happening outside the platform:
The pattern: the system holds the record, but the coordination and inventory work around it still lives in calls, sheets and paper.
Some observations remain uncertain. The feedback does not establish whether a walk-in flow or price list exists but is unused, and its attribution of location-related billing errors is tentative. Those points need clarification before becoming definitive portfolio claims.
8. Outcomes and next evaluation
The confirmed delivery outcome is a platform now used in the clinic. The design material shows progression from treatment-stage and task concepts to more detailed operational workspaces, and live stakeholder feedback identifies where the current product still fails to support clinic practice.
No quantified improvements in task time, error rate, missed follow-ups or adoption have been supplied. The measures below are future evaluation proposals, not tests or outcomes claimed for the project.
| Goal | Suggested evidence to collect |
|---|---|
| Improve clinical-to-billing handoffs | Can front desk identify performed services without contacting the doctor? |
| Support accurate appointment states | Can staff record completion or no-show after the scheduled time? |
| Preserve financial continuity | Can staff recover the agreed package price and payment history? |
| Reduce repeated coordination | How many channels or duplicate updates does a handoff require? |
| Reuse patient information | How often do staff re-enter information already captured? |
| Support stakeholder workflows | Task completion and observed friction in each role’s own account. |
9. Reflection
The most consequential shift in this project was moving from understanding IVF as a treatment journey to understanding the clinic as an interdependent service.
The initial stage model helped make the treatment structure visible. Operational workspaces addressed the different responsibilities of the people delivering care. Feedback from the current platform then showed that a shared interface does not automatically produce a reliable handoff: system rules, ownership and timing must also match how the clinic works.
For the next version, the opportunity is to close those gaps while preserving the capabilities staff already rely on. The design challenge is to make responsibility, patient context and the next action explicit across the service.
Thanks for reading.