Getting five people ready before a shipment moves.

Before drawing a single screen, I mapped how a shipment actually moves: a fragile, temperature-controlled package changing hands across two clinics and a courier, on a tight medical deadline. A wrong label or a missed temperature drop isn't just an inconvenience here. It can mean losing someone's only remaining embryo.

Don, the owner, put it simply: a shipment "looks like one transaction to the patient, but it is actually a chain of separate responsibilities", the patient, two clinics, a courier, and IVFCRYO, each with its own paperwork and approvals. So the first thing I built wasn't a screen. It was a map of who owed what to whom.

I asked all three people I interviewed what they'd fix first, and all three named the same thing: a shared readiness check that both clinics confirm before a courier is scheduled.

The worst pattern, Daryl told me, is "scheduling first and hoping the remaining requirements are completed before pickup." It happens because someone is trying to protect a patient's transfer date, and it sometimes ends in a last-minute cancellation instead. So I built readiness as something the system checks, not just an impression someone has: a requested date, a provisional plan, and a confirmed shipment stay three separate things, instead of all looking the same the way they did on paper.

A customer needs a short, reassuring path from request to tracking. The IVFCRYO staff member lives in the tool all day and needs to see every shipment and every client at once. Building two separate apps would have been simpler, but each would keep its own record of a shipment, and the two could drift apart and disagree, exactly the problem the app exists to fix.

Instead, both sides read from one shared shipment record. A readiness view now sits on the customer side too, since Sasha's hardest daily work was chasing "what are we still waiting for?" across email, fax, and clinic portals.

A mistyped address or a name that doesn't match a clinic's records isn't a small form problem here, it's a risk to someone's only embryo. So every form helps people avoid mistakes, explains them clearly when they happen, and lets someone fix them without calling support. Addresses get checked against real map data, and specimen details are captured as structured fields instead of free text.

IVFCRYO's shipping guarantee, CRYO Shield, only pays out on a claim that's fully documented, so the order form also captures the declared value and protection tier, and receiving captures a temperature reading and photos right away. As Daryl put it, "the claims process begins long before a claim exists."

A legally blind customer tested the app with a screen reader from early on, and kept testing after launch, which is how the labeling issue in the edges below got found. Status and errors always show as text and icons, never color alone, and important updates get read aloud automatically instead of only appearing silently on screen.

An app can only promise what the system behind it can actually deliver, so I didn't just design the screens and hand them off. I worked alongside the engineering team on the parts that had to carry those promises.

I turned the interview findings into the shipment stages and the readiness check the system had to enforce, mapped out where each carrier and outside service should plug in, and set the requirements for monitoring and alerts. Engineering built the backend. I built the front-end components and the specification they had to meet.

A patient could now see that both clinics had signed off instead of calling to ask. The office team could open one case instead of piecing it together from email, fax, and phone notes. And because scheduling waited on readiness, fewer couriers were sent before a clinic had actually released the specimens.