Role: AI-Native Designer & UX Validation Lead
Timeline: 14 months · 2025–2026
Stage: Alpha prototype → User testing → Closed beta on TestFlight → MVP validation
Team: Founders (CEO, co-founder), Product/Tech Lead, Developer, UX Researcher, Chief Science Officer, Clinical Advisors
Website: https://www.omaia.ai/
Detailed flows and visuals limited under NDA.

The starting point

When I joined Omaia in early 2025, the product was a deck and a feeling. The founders knew the who (pregnant people carrying anxiety the rest of the world didn't see) and the why (most pregnancy apps point at the baby; almost none point at the parent). What was missing was the what and the how — what would the app actually be, and how would someone tired, nauseous, and overwhelmed at 9pm actually use it?

I came in as Product Designer and within a few weeks the role had grown — UX lead, validation lead, user communication lead, occasionally PM glue. Small startup, big surface area.

Chapter 1 — From idea to Alpha

I worked side-by-side with one of the co-founders in the early weeks. She talked, I designed. Figma open, conversation running, ideas landing on the canvas in near real-time. That speed — being able to make a half-formed thought visible inside the same hour it was spoken — became the way we worked.

The Alpha came together as a prototype designed to answer one question: would a pregnant person open this twice?

Key decisions I made or pushed for in this phase:

• Calm over informative. Most pregnancy apps treat the user as a data point in a fetal timeline. I argued for a homepage that didn't lead with weeks-pregnant or baby-size comparisons. The user is the user. Not the baby.

• Low-cognitive-load patterns. Short flows, large touch targets, dark mode from day one, progressive disclosure. Designed for someone exhausted, not someone fresh.

• Three fear profiles, not one funnel. Working with the Therapist in our team, we structured the app around three distinct anxiety profiles (primary childbirth fear, trauma-linked childbirth fear, pregnancy health anxiety). One product, three pathways. This shaped every flow downstream.

Chapter 2 — Validation Round 1

I planned and ran the first validation round on the Alpha prototype, built in Lovable for speed. I also recruited and onboarded a UX researcher to work alongside me — my first time bringing someone into the research function rather than just executing it.

What I owned in this round:

• Defined the research questions (trust, clarity, perceived value, willingness to return)

• Prepped interview guides, consent forms, and recruitment outreach

• Ran interviews with pregnant users across the three fear profiles

• Synthesised qualitative feedback into a prioritised list of design changes

• Reported findings back to the founders and clinical team

The headline finding was uncomfortable: the product worked, but it was lonely. Pregnant users kept describing what they did when worry rose — they texted a partner. A friend. Their mum. The app was solo by design, and the actual coping pattern was social.

I wrote up the insight and proposed a partner/support feature. The team listened, agreed it was interesting, and parked it. Not the priority right now. Build the core first.

I documented it and moved on.

Chapter 3 — Designing Maia, the AI companion

Parallel to the validation work, I co-designed Maia, Omaia's in-app AI companion, with the team's AI prompt engineer and developer.

This was my first time designing something whose behaviour mattered as much as its interface. We weren't deciding what Maia looked like (chat bubble, no avatar). We were deciding what she sounded like when a user said "I'm scared something is wrong with the baby" at 2am.

I prototyped Maia's conversational behaviour in Lovable and Claude Design, iterating on tone, response length, when to validate versus redirect, when to suggest an exercise versus simply listen. The prompt engineer owned the model logic; I owned the experience of being on the receiving end. We met in the middle constantly.

What I learned doing this:

• Designing AI behaviour is closer to UX writing than UI design — but the writing has to anticipate thousands of inputs, not one.

• The interface is the easy part. The hard part is deciding what the system should refuse to do (Maia doesn't diagnose, doesn't reassure with false certainty, doesn't replace clinical care).

• You iterate by reading transcripts. That's the loop. Real user inputs in, response tuning out.

Chapter 4 — Closed Beta on TestFlight

I took everything from Round 1 — the IA changes, the trust touchpoints, the calmer homepage, the cohort-specific exercise flows, the early Maia — and rebuilt the product into a closed Beta. Launched on TestFlight with ~80 pilot users, structured across the three fear-profile cohorts and tracked with Looker analytics.

I designed the validation infrastructure to run alongside the build:

• T0 (onboarding), T1 (mid-program), T2 (program end) assessment cadence

• Weekly engagement snapshots: activation, retention, drop-off, exercise completion, fear-profile-specific patterns

• Interview rounds at Module 4 and Module 8 to layer qualitative on top of behavioural data

• Structured weekly reports back to the founders, with the same three sections every time: signal, watch, flag

The reporting cadence became something the team relied on. It also forced me to make a clean separation between positive momentum (Signal), passive monitoring (Watch), and needs a decision (Flag).

Chapter 5 — Support Circle

Six months after I'd first proposed the partner/support concept and watched it get parked, the founders came back to me. Investor conversations had surfaced the same gap I'd flagged from user interviews. Could you do a concept for the next phase?

What I delivered: a fully-scoped concept for Omaia Support Circle — a way for a pregnant user to invite one chosen support person into a limited, bounded, user-controlled view of the app.

I delivered the concept as a Figma prototype, a presentation deck, and a written specification covering scope, boundaries, governance, and open questions for clinical review.

Roles I held on this project

Product Design Lead · UX Validation Lead · User Communication Lead · Acting PM (partial) · Research Recruitment & Coordination · Co-designer on AI Companion (Maia)

Skills demonstrated

Product Design · UX Leadership · AI Companion Design · MVP Validation · User Research · Engagement & Retention Analysis · Looker Analytics · Design Systems · Accessibility · UX Writing · Project Planning · Stakeholder Management · Cross-Functional Collaboration · Claude Code · Lovable · Figma · Figma Make · Claude Design

What I took away

A few things I now know about myself as a designer that I didn't know going in:

• I do my best work when I'm in the room with non-designers — founders, clinicians, engineers. The translation layer is where I add the most value. I also am comfortable with wearing multiple "hats".

• I'm comfortable owning the messy middle. Validation, project glue, stakeholder communication, the weekly report nobody wants to write. The work that makes design decisions stick.

• I'm willing to flag something six months before it's wanted, and be patient with it. Quietly.
  
  Prototype available on request.