wawa
At wawa I work across the full product lifecycle (research, design, and frontend implementation in React/Next.js) for clinical software used by fertility clinics across the UK, US, Canada, and Australia.
At wawa I work across the full product lifecycle (research, design, and frontend implementation in React/Next.js) for clinical software used by fertility clinics across the UK, US, Canada, and Australia. In a flat-hierarchy startup team, my role has spanned everything from patient-facing clinical flows to internal regulatory infrastructure, often taking a feature from first sketch through to shipped code.
Overview
wawa builds clinical software for fertility clinics, spanning patient intake, clinical workflows, scheduling, cryo storage and donor management, and the regulatory reporting clinics are legally required to submit. As a senior product designer who also ships frontend code, I’ve worked on projects ranging from ground-up platform builds to targeted redesigns of clinical paperwork, each shaped by close collaboration with clinic partners and a small, fast-moving internal team.
Tasks & responsibilities
Across my time at wawa I have…
- Owned design end-to-end (research, UX, UI, and React/Next.js implementation) rather than handing off to a separate engineering team.
- Ran discovery directly with clinic partners across the UK, Australia, the US, and Canada to ground product decisions in real clinical workflows, not assumptions.
- Worked across a multi-jurisdiction product, designing for the regulatory and clinical differences between UK, US, Canadian, and Australian fertility clinics.
- Worked in a flat-hierarchy team where designers carry projects further than a typical handoff model, from research through to shipped frontend code.
Project: Two-sided clinic onboarding platform
Overview
Designed and built a two-sided onboarding platform to bring new fertility clinics onto wawa’s software. Onboarding a clinic means walking them through configuring dozens of interdependent settings (products, medical codes, tax rates, price lists) before the platform is usable, and the process had grown ad hoc as the product grew, with no dedicated flow guiding a new clinic through it in the right order.
Problem
Losing work on missing dependenciesCreating something as simple as a product required a medical code and a tax rate to already exist. If they didn't, the person configuring the clinic had to abandon the form, go create the missing dependency elsewhere, and start again, losing their work each time.
Bulk import was hiddenA faster path existed for clinics with large catalogues, but it was admin-only and undocumented, with no template or guidance on the expected file structure, so the clinics who needed it most often didn't know it existed.
Settings were disconnectedRelated concepts (medications and products, tax rates and price lists) lived in separate, unrelated parts of the settings area.
Training didn't scaleLarger clinics were still relying on multi-day, in-person training to get set up at all, which doesn't scale past a handful of rollouts a year.
Contributions
- Designed an inline “create new” pattern for dependency fields (medical codes, tax rates) directly inside the form that needs them, so configuring a clinic no longer means losing your place and starting over.
- Designed contextual nudges toward bulk import for clinics adding items one at a time, plus a downloadable CSV template and a column-mapping step, so bulk import stopped being an admin-only, undocumented feature.
- Restructured the settings information architecture so related concepts (price lists, medications, tax rates) sit together instead of being split across unrelated tabs.
- Designed a guided setup flow: a self-serve questionnaire at a dedicated URL, answerable before a clinic even logs in, that adapts based on the clinic’s jurisdiction and the integrations they need, replacing a static document-based intake process.
- Built the frontend in Next.js 15 with InstantDB as the data layer, including setting up the local development environment for the project from scratch.
Outcome & impact
The onboarding demo of the guided setup work got a strong internal response and was chosen to be shown at the company all-hands as a template for how implementation should work going forward, standardised and repeatable rather than a bespoke, largely manual process per clinic. It’s an active initiative rather than a finished, measured result, but it reframed onboarding from something wawa does to a clinic over days of training, toward something a clinic can largely configure themselves.
Project: Clinical flow redesigns
Focus areas: Donor flow · Lab sheets · Stim sheets · Clinical task management
Overview
Redesigned several core clinical workflows used daily by clinic staff: stimulation medication tracking during a treatment cycle, donor and cryo storage management, and the paper lab sheets embryology teams still relied on day to day.
Stim sheets and clinical tasks
The problemExtending a single medication on the tracking sheet took seven or more clicks (open edit, scroll, change the date, save, wait for the page to refresh and re-scroll to where you were). A patient on five medications meant repeating that five times, several times a day, across many patients at once.
A useful benchmarkA clinician showed a competitor product that solved the same problem with a double-click on the target date, useful as a benchmark, not a template to copy outright.
Redesigned interactionReworked medication extension around direct manipulation instead of a multi-step edit flow.
Related task list reworkSeparately reworked the day-to-day clinical task list (used to sign off consents and complete clinical steps) around an email-inbox-style model: auto-advance to the next item, keyboard shortcuts, and default filters like "overdue" and "today", since this was a workflow clinicians touched dozens of times a day, not a once-a-month feature.
Donor flow
The problemThe donor management flow had accumulated as a series of individual fixes to specific client-reported issues rather than being designed as one coherent workflow. It showed: a donor reservation system that felt bolted on, and inventory visibility that existed but was buried in the wrong part of the product entirely.
Redesigned as one sectionBuilt a proper "Donors" section inside cryo storage, with a filterable table for matching donors against criteria clinics actually search on.
Consolidated dashboardA donor dashboard surfaces family limits, storage, and any holds or restrictions in one place rather than scattered across separate screens.
Lab sheets
The contextEmbryology labs run on printed lab sheets, physically carried between the bench, the incubator, and storage.
First framingAuto-generate a pre-filled PDF from a patient's active cycle so staff could print it, fill it in by hand, and scan it back in.
The problem with that planFilling in a printed sheet by hand and then re-entering that same data digitally is exactly the kind of duplicate data entry clinics are already drowning in.
The pivotShifted the design to treat the lab sheet as a live view of data that already exists in wawa rather than a form to fill out, with a QR code as the bridge back to the physical world: scan the code on a sample or tray, and the corresponding digital sheet opens directly, already populated.
Contributions
- Redesigned the medication extension interaction on stim sheets from a multi-step edit flow to direct manipulation, and audited and fixed a set of related chart-rendering and task-list bugs raised directly by clinicians.
- Reworked a clinical task list into an inbox-style model with auto-advance, keyboard shortcuts, and smart default filters, aimed at reducing the sheer number of clicks in a workflow clinicians repeat constantly throughout the day.
- Redesigned the donor and cryo storage flow around a dedicated, filterable donor section with a consolidated status dashboard, replacing a workflow that had grown as a series of disconnected patches.
- Reframed lab sheet digitisation from a print-and-scan pattern to a live, QR-code-linked digital view, avoiding a new source of duplicate data entry for embryology staff.
Project: Referrals & patient intake CRM
Overview
Designed a CRM for managing how patients enter a clinic’s care, from formal referral documents through to online booking links and marketing sign-ups, with AI-assisted extraction to auto-populate patient records from uploaded referral documents rather than requiring manual transcription.
Problem
"Referrals" was too narrowPatients arrive via referral letters, but also web booking forms, direct sign-ups, and marketing channels, and all of them needed the same intake workflow.
Leads mixed into patientsPatients created from these different sources were mixed into the main patient table with no way to tell them apart.
No duplicate detectionThere was no way to catch a duplicate patient being entered twice.
No expiry visibilityReferrals with a natural expiry window had no dedicated view surfacing which ones were about to lapse, so staff had to know to go looking for them.
Contributions
- Reframed “Referrals” as a broader intake workflow view spanning every source a patient can enter through, rather than a separate store just for referral documents.
- Defined an explicit patient lifecycle (from unprocessed through to booked and in treatment) so intake stays a working queue instead of quietly accumulating stale records.
- Designed a duplicate-patient detection flow that surfaces a match by name or email at the point of entry, before a second record gets created.
- Designed the review flow around AI-assisted document extraction: staff upload a referral document, the system extracts patient details automatically, and staff verify and correct the extracted fields rather than transcribing them from scratch.
- Designed a dedicated expiring-referrals view so time-sensitive referrals surface proactively instead of requiring staff to filter for them manually.
Project: Patient health information capture
Overview
A large undertaking to fix where the product’s health data actually came from and how usable it was once captured: consolidating every clinic’s separate intake survey into one customisable master survey, moving primary data collection from clinician to patient, and making sure everything captured was structured enough for the rest of the platform to actually use.
Consolidating clinic surveys into one platform-wide intake
The problemEvery clinic on the platform had accumulated its own intake survey over time, each asking a different mix of largely the same underlying clinical questions in different wording, with no shared source of truth.
Audit and consolidateWent through every clinic's existing survey, extracted every unique question being asked anywhere, and merged them into one master survey covering the full superset.
Customisable per clinicEach clinic only shows the questions relevant to its own workflow, instead of every clinic separately reinventing, or losing, questions over time.
Structured and quantifiable onlyEvery field is a dropdown, checkbox, or discrete input, never free text, so answers can be validated, searched, and fed into the rest of the platform rather than just sitting in one patient's file.
Shifting who captures the data
The problemHealth history was largely gathered by a clinician or doctor asking questions during an appointment and writing down the answers, spending consultation time on data entry rather than care.
Patient becomes the primary sourceRedesigned the flow so the patient's own answers, submitted through the app before or between appointments, become the primary source of that data.
Clinician role shifts to reviewThe clinician's job moves from collecting the data to reviewing what the patient already provided and accepting it.
Making that shift possibleRedesigned the questionnaire itself into a guided, mobile-first experience broken into seven themed sections (cycle history, contraception history, partner history, medical background, lifestyle, family history, and goals), with a visible progress indicator, conditional questions, and softer section framing ("Your Cycle Story" rather than "Menstrual History"), without losing any of the clinical precision the data needs.
Clinician-facing review viewThe same answers render into a categorised, scannable table using clinical labels ("Pain during sex") rather than the original patient-facing question wording, so reviewing a completed intake means reading a chart, not a transcript.
Flow sheet view and shared data
Data shared platform-wideBecause every answer is captured as structured data rather than free text, a single data point (a survey answer, a lab value, a vital) is shared platform-wide instead of staying trapped in the form it was originally collected on.
Flow sheet viewClinicians can see how any individual data point has changed across visits rather than only its current value.
Notes on any data pointAny specific data point in that history can have a note attached to it directly.
Obstetric history, UK vs USA related, more specialised structured-capture problem: the UK typically records Gravida and Para as two numbers, while US practice (per ACOG) uses the fuller GTPAL notation. Built a single recording interface that toggles between the two, auto-calculates derived values, and validates against clinically impossible entries (more living children than recorded deliveries, for example), always showing a plain-language summary alongside the shorthand.
Outcome & impact
This work also closed a concrete gap elsewhere in the product: several patient-record fields the UK’s HFEA reporting integration required were frequently missing entirely, because there had never been a structured, upfront point to capture them. Feeding those fields into the consolidated survey meant they were captured naturally as part of a patient’s own intake rather than chased down later by staff, and materially reduced the missing-data gaps that were previously showing up as reporting errors.
Contributions
- Audited existing intake surveys across the clinic base and consolidated every unique question into one master, per-clinic-customisable survey, with every field structured and quantifiable rather than free text.
- Shifted the primary source of patient health data from clinician-collected to patient-self-reported via the app, redesigning the questionnaire itself into a guided, mobile-first, sectioned experience a patient would complete unsupervised.
- Designed a clinician-facing review-and-accept flow, and a results view translating patient-facing question wording into clean clinical labels for fast scanning.
- Designed a flow sheet view showing how any shared data point changes across visits, with the ability to attach notes to individual data points.
- Designed a dual-standard obstetric history recorder supporting both UK (Gravida/Para) and US (GTPAL) conventions, with auto-calculation and validation against clinically impossible entries.
- Closed gaps in commonly-missing HFEA regulatory fields by capturing them at the point of patient intake instead of after the fact.
Project: Multi-jurisdiction regulatory reporting framework
Problem
Four regulators, four formatsFertility clinics must report clinical data to different regulatory bodies depending on jurisdiction (HFEA/PRISM in the UK, ANZARD in Australia/NZ, SART in the US, and BORN), each with its own data requirements, formats, and submission mechanism.
Fully disconnected taskReporting was bolted onto the end of clinical work: staff re-entered data that often already existed elsewhere in the clinic's systems.
No outstanding-submission visibilityNo way to see which patients still had outstanding submissions short of running a manual report and checking each record by hand, and no reminders for approaching deadlines despite real regulatory consequences for missing them.
Real error ratesClinics estimated meaningful error rates under this manual process, which lines up with public regulatory data: the UK's HFEA board has reported clinics submitting through third-party integrations average a 6 to 8 percent error rate, against under 1 percent for clinics submitting directly.
Approach
Rejected the obvious approachReached with the product lead early on: don't build dedicated "reporting forms" for staff to fill in, since that just relocates the same manual data entry problem into a new screen.
Verification, not formswawa already captures the underlying clinical data (registrations, cycles, procedures, outcomes) as a byproduct of normal clinical workflow, so the reporting feature became a dashboard over that existing data showing what's ready, what's missing, and what's invalid, with submission reduced to a single action once a record is complete.
Canonical data, per-jurisdiction mappingEach data field is stored once in a canonical form and mapped to whatever format a given regulator expects only at submission time, so the same underlying record can satisfy multiple regulators' differing field formats without duplicating data entry per jurisdiction.
Contributions
- Designed the reporting dashboard: a single view of every patient’s reporting status (ready, needs attention, overdue, submitted) replacing a fully manual, per-patient checking process.
- Designed the canonical-data-plus-per-jurisdiction-mapping model underpinning the framework, so one underlying record can generate a compliant submission for multiple regulatory bodies instead of maintaining separate data entry per jurisdiction.
- Designed a flow for importing a patient’s pre-existing registration from a prior clinic (regulators generally allow only one registration per patient), surfacing that history read-only rather than blocking or duplicating it.
- The UK’s HFEA/PRISM integration was the first full implementation of this framework, built and validated directly with clinic partners; ANZARD, SART, and BORN share the same underlying data model, submitting via CSV export rather than a live API.
Outcome & impact
In review with clinic partners, the shift from “fill in a form” to “confirm what’s already correct” was the single most positively received change: clinics specifically called out not having to log into the regulator’s own portal at all as a meaningful win on its own, before any of the deeper validation or bulk-submission tooling even shipped.
Project: Scheduler v2
Overview
Led discovery for a second-generation scheduling system, working directly with clinic partners to understand where the existing scheduler fell short of real clinical booking needs.
Problem
No recurring unavailabilityThe scheduler had no way to express recurring unavailability (lunch breaks, non-bookable hours) or restrict which appointment types could be booked in which windows, which for at least one clinic was serious enough to threaten their go-live timeline.
No linked, multi-resource bookingsA clinic walked through a "treatment scan" appointment type that needs to book two different resources with a staggered offset: fifteen minutes on a sonographer's diary, followed automatically by fifteen minutes on the phlebotomy list right after, booked as one unit. The existing scheduler had no concept of a single appointment type driving multiple linked, offset resource bookings.
Contributions
- Ran discovery sessions with clinic partners to surface real scheduling constraints rather than assumed ones, including the recurring-unavailability gap and the multi-resource linked-appointment requirement.
- Scoped an initial “Schedule Templates” concept covering recurring blocked time and per-appointment-type booking windows as the fastest path to closing the most urgent gap.
- Documented the multi-resource, staggered-offset appointment requirement as a core input to the v2 scheduling model, since it wasn’t something the existing single-resource booking model could represent at all.
This project is still in the discovery and early design phase rather than shipped.
Reflections & key takeaways
- The regulatory reporting project taught me the most about designing in a legally constrained space: the temptation is always to build the thing the regulator’s form literally asks for, but the better answer was almost always to ask what data already exists in the product and design the smallest possible layer on top of it.
- That instinct, treat a new requirement as a lens over existing data rather than a reason to ask users for more input, showed up again in the lab sheets project, where the obvious first answer (print a form) would have quietly made the underlying duplicate-data-entry problem worse rather than better.
- Working in a flat-hierarchy startup changed how I think about ownership. There’s no separate handoff to engineering here: a feature I design, I frequently also build, which means design decisions have to hold up against real implementation constraints from day one, not get revisited after the fact.
- Discovery across UK, US, Canadian, and Australian clinics made clear how much “the same feature” can differ once you take local regulation, terminology, and clinical convention seriously, rather than designing for one market and treating the rest as a localisation afterthought.