Skip to content
myJourni phone mockup on cyan with the headline Your personalized healthcare journey assistant

MYJOURNI / FEWER BARRIERS TO CARE

Make the appointment
a plan you can keep.

One care need.
One confirmed plan.

Follow the journey

Book the whole morning.
Not just the appointment.

A provider who accepts your plan. A cost you understand. Childcare for the visit. A way to get there. myJourni connects these separate decisions into one coordinated care journey, so a booking becomes a plan someone can actually follow.

Explore the app demo
WHAT I BUILT
Product strategy, UX & full-stack delivery
COLLABORATION
Maternal-health and payer-operations expertise
THE PRODUCT
Member experience & care coordination

01 / Context

Finding a doctor is only the beginning.

The starting point was a maternal-health access challenge: people were being asked to coordinate a fragmented system at precisely the moment they needed support. A provider directory could answer where to go. It could not resolve everything that stood between choosing a visit and attending it.

I reframed the work around a complete care need. The requirements had to account for time, cost, family responsibilities, transportation, and continuity with a care team, not simply the next available slot.

THE PROBLEM / 1:39

What stands between a need and care?

The problem film introduces the access and coordination challenge behind myJourni.

A shared vehicle

Build transportation around the confirmed time and location.

Children who need care

Reserve a childcare window that includes the visit and travel.

Uncertainty about cost

Show a coverage-based estimate before committing to a slot.

A disconnected care history

Request consent to reconnect the existing care team, with a preference-based fallback.

02 / People & workflow

One plan. Different people making it possible.

The member

Can I make this visit happen?

A single thread connecting provider, cost, childcare, and the ride.

The care team

What needs attention before the visit?

Questions, visit context, and follow-up carried into the care journey.

The navigator

Who needs help before a missed visit?

Unresolved support arrangements and scheduling exceptions.

The support partner

Where, when, and for how long?

Reservations tied to the appointment and its real travel window.

The plan team

Is coordination changing access?

Care-need progress and source-defined evaluation measures.

THE SHARED CARE-NEED LIFECYCLE

  1. 1Raised
  2. 2Matched
  3. 3Priced
  4. 4Scheduled
  5. 5Supported
  6. 6Attended
  7. 7Followed up

03 / My contribution

The model, the product, and the story around it.

I carried myJourni from product definition through the materials that made the product legible: translating the coordination problem into requirements, an explicit domain model, conversation logic, interfaces, implementation, and a commercial story people could understand.

The pivotal distinction is Care Need versus Appointment. An appointment is a calendar commitment. A care need can hold the estimate, the booking, childcare, transportation, and follow-up. That is the foundation of a connected plan.

I authored the problem and solution scripts, created and directed the cloned AI voice, produced the After Effects films, and created the animation, transitions, pacing, and visual treatment. The featured care-navigation app began in Figma and now exists as a React-based product experience. Clinical content and journey validation remained collaborative responsibilities with subject-matter experts.

co-owned

Problem discovery and the coordination reframe

Problem statement, care desert research, provider distance and assignment analysis

owned

Business and journey requirements

Action-step and prompt requirement tables covering scheduling, cost, transport, childcare, what-to-expect, check-in, and follow-up

owned

Domain model and data contract

Preference and profile schema mapped onto the payer's USCDI v3 data classes; prior-payer care team import via interoperability

owned

System behavior and conversation orchestration

Prompt-by-prompt specification with branch logic, guided-option sets, and confirmation states

owned

UX design, end to end

Chat thread, provider card, slot picker, childcare confirmation, itinerary card

owned

Frontend implementation

Working prototype used for the pilot walkthrough

owned

Backend orchestration and integrations

Sequencing of match, cost estimate, scheduling, childcare and rideshare booking; email confirmation path

collaborated

Clinical content and journey validation

Subject matter expert review of trimester content, testing expectations, and medication-related guidance

influenced

Entry points, community partnerships, go-to-market

Six-channel entry point plan across community partners, retail, providers, agents, plan service, and digital

co-owned

Pilot design and funding case

Two-phase validation plan with scoped budget and duration

owned

Product narrative and commercial pitch

Defined the problem and solution story, wrote both film scripts, and shaped the case-study narrative around the product's coordination model

owned

Film direction and motion production

Created the AI-voiced narration, produced the After Effects films, and authored the animation, transitions, pacing, and visual treatment

owned

Product interface design and implementation

Designed the featured care-navigation app in Figma and carried the experience into its React-based implementation

THE DOMAIN MODEL

Member / Preference Profile / Care Team / Care Need / Provider/Offering / Cost Estimate / Appointment / Support Arrangement / Journey Stage / Check-in

04 / Options considered

The choices that defined the product.

The question was not how many features to add. It was which choices would make one complete care journey possible, and which complexity belonged outside the first release.

01Conversational assistant vs. faceted search-and-filter directory

OPTION A

Guided conversation with contextual option chips

Strength: Carries state across four dependencies; reaches a confirmed plan in one pass; low literacy and low patience cost

Tradeoff: Poor at broad comparison; hides the size of the option space; hard to browse

OPTION B

Adjustable faceted search over the provider network, hotel-booking style

Strength: Real comparison across distance, availability, reviews, provider type; member stays in control of tradeoffs

Tradeoff: Assumes the hard part is choosing; leaves cost, childcare, and transport as separate errands

The decisionConversation as the primary surface, with structured chips — dates, time slots, rideshare vendors — inside the thread. Faceted refinement deferred to the point where a member has a care team and is choosing between alternatives rather than trying to get seen at all.

02Build the navigation layer vs. extend existing scheduling platforms

OPTION A

Build orchestration, member experience, and data layer in-house; integrate third parties for slot inventory and rides

Strength: Owns the care need object, the coordination logic, and the member relationship

Tradeoff: Integration surface area; dependent on partner availability and reliability

OPTION B

Extend what existing appointment marketplaces already do

Strength: Provider inventory and booking already solved at scale

Tradeoff: Extending booking alone would leave childcare, transportation, and the shared care plan outside the core product.

The decisionOwn the member experience and coordination logic; integrate partner services for appointment inventory and transportation. This preserves the care-need model while accepting integration reliability as an operating responsibility.

03Launch scope — full maternal platform vs. one care need end to end

OPTION A

Cupcake: the first prenatal care need, fully orchestrated, including cost, childcare, and transport

Strength: Testable; the whole value proposition is provable in one flow; short feedback loop

Tradeoff: Looks thin next to the feature map; engagement between care needs is unaddressed

OPTION B

Wedding cake: seven feature families, wearables, community, points economy at launch

Strength: Retention story; broader value narrative to a plan sponsor

Tradeoff: Nothing proven; the coordination hypothesis is never isolated

The decisionCupcake. Community connection, gamification, wearable integration, nutrition, doula search and food and housing referrals all documented as later opportunities — see Module B.

04Audience boundary — health-equity population at large vs. maternal cohort in one geography

OPTION A

Maternal health in the Allapattah / Liberty City cluster

Strength: Short outcome window; measurable clinical endpoints; a bounded provider and partner network to actually contract with

Tradeoff: Smaller addressable population; solves one journey, not the mandate

OPTION B

The whole under-65 ACA population facing access barriers

Strength: Matches the original mandate; larger commercial story

Tradeoff: No shared lifecycle to build a product around; no measurable endpoint inside a pilot window

The decisionStart with a bounded maternal-health journey and local partner network, then test whether the coordination model transfers to other care needs.

05Geofenced push entry vs. member-initiated entry

OPTION A

Member opens the app when a need arises

Strength: Clear member intent without requiring a location-triggered entry point.

Tradeoff: Misses the moment of maximum need — the pharmacy, the positive test

OPTION B

Geofenced prompt on leaving a healthcare location: 'how was your Walgreens experience, can I help with anything?'

Strength: Catches the need at the exact moment it forms; converts a retail visit into a care plan

Tradeoff: Location tracking around health facilities is a serious consent and perception problem for a payer

The decisionMember-initiated as the core path. The geofenced prompt was kept as the film's opening because it is the strongest illustration of the timing problem, but scoped as a pilot-only experiment pending consent review — not a shipped behavior.

05 / Design decisions

Reduce uncertainty before asking for commitment.

Continuity before another search

Offer the existing care team when consent and data allow. Keep alternatives available instead of forcing a single recommendation.

Cost before the calendar

Make the estimate visible before a member chooses a slot. The estimate is a decision aid, not a guarantee of final responsibility.

Confirm a plan, not a fragment

Connect childcare and transport to the visit duration and location. If a support fails, preserve the appointment and expose the unresolved need.

Make the plan portable

Keep confirmations in the conversation and email. Offer reminders at each commitment rather than relying on the member to reopen the app.

Check-ins with accountable handoffs

Carry questions and context forward. Clinical review and explicit escalation boundaries remain essential; the interface is not a substitute for care.

Consent is part of the experience

Ask before retrieving prior-payer data. Make fallback matching understandable when consent or records are unavailable.

Cost enters the decision before the member commits to an appointment.
myJourni presents visit cost before available appointment times

Cost enters the decision before the member commits to an appointment.

06 / The experience

One thread, from a need to a coordinated day.

THE SOLUTION / 1:46

See the product come to life.

The solution film is a commercial pitch for the experience I designed, animated, and implemented: a connected journey from need to care.
01

detect the need

A short set of guided options; pregnancy, then a single clarifying question

Behind the experienceOpens a Care Need against her Member record and current Journey Stage

02

match

Her prior care team doctor named, with role, location, address and phone

Behind the experienceResolves Care Team from prior-payer interoperability data with consent; falls back to Preference Profile matching where absent

03

price

The cost of this visit under her coverage, stated before any dates

Behind the experienceGenerates a Cost Estimate against her benefits for the offering matched

04

schedule

Soonest available dates as chips, then time slots inside the chosen date, then a written confirmation with visit duration

Behind the experienceBooks the Appointment, records duration, emails a copy

05

arrange the supports

A childcare window with its reasoning stated, then a rideshare vendor choice, then a three-stop itinerary card

Behind the experienceCreates Support Arrangements chained to the appointment's real duration and location; emails each confirmation

06

remind

An inline opt-in at each commitment, and emailed details she can find without the app

Behind the experienceSchedules notifications against every element of the plan, not just the appointment

07

follow up

A post-visit check-in, the next appointment her care schedule calls for, and a stage-aware daily check-in between visits

Behind the experienceAdvances the Care Need state, opens the next one, carries the Check-in log into the next visit

Reconnect the care team, then offer a clear next action.
myJourni identifies a prior care-team provider

Reconnect the care team, then offer a clear next action.

Childcare is part of the plan, not a separate errand.
myJourni confirms a childcare reservation

Childcare is part of the plan, not a separate errand.

A transportation itinerary carries the appointment into the real world.
myJourni rideshare itinerary with the journey's stops

A transportation itinerary carries the appointment into the real world.

One entry point for a connected healthcare journey.
myJourni mobile app introduction

One entry point for a connected healthcare journey.

The incomplete states are part of the product.

empty

No prior payer data or no consent — matching falls back to the Preference Profile and states that it has done so

exception

Childcare unavailable in the window — the appointment holds; virtual visit, alternative slot, or alternative partner offered; care need marked scheduled-but-unsupported

degraded

No rideshare availability — the appointment holds and transport surfaces as an unresolved exception rather than a failed booking

permissions

Explicit consent requested before any interoperability pull; consent recorded against the Member

audit trail

Every confirmation exists in the thread and in her email; past and future visits available in an appointment tracker

language

Profile-level language setting governs both matching and content, English and Spanish

Walk through the app

07 / Evidence & value

Measure the plan that becomes an attended visit.

The supplied case study reports a 14-week pilot with 184 members in Miami-Dade and a matched comparison cohort. Its central evaluation question is whether coordinating the supports changes attendance, not simply whether the app produces more bookings.

REPORTED PILOT RESULTS / SUPPLIED CASE STUDY

87%

Kept-appointment rate

Compared with a reported 61% matched baseline.

6m 30s

Median time to a complete plan

Compared with a self-reported four-day baseline.

547

Confirmed care plans

From 612 reported care needs; 374 included support.

Figures reproduced from the supplied case study, not independently verified here. Source documentation contains conflicting pilot-provenance notes; reconciliation is pending. Read the source case study

Test the coordination hypothesis.

The reported kept rate was 91% with a support arrangement and 74% without one. That comparison motivates further evaluation; it does not, by itself, establish that the product caused the difference.

Keep the gaps visible.

The source also reports check-in completion declining from 71% to 44% and unmet requests for Haitian Creole. Retention and language access belong in the next iteration, not outside the success story.

MODELED COMMERCIAL SCENARIO / NOT REVENUE

$720K annual recurring revenue

The supplied commercial model assumes 100,000 covered lives at $0.60 per member per month across 25 groups. This is a scale scenario, separate from pilot observations and not a claim of realized sales.

08 / What comes next

A first journey. A broader coordination model.

Maternal health establishes a bounded lifecycle and a local support network. Expansion should prove that the same care-need model can support another journey without turning each new sponsor into a separate product.

The next layer is operational: role-specific views, partner availability, consent revocation, payer-data separation, auditability, and visible exception queues. New geographies and language packs need real service coverage behind them.

Deepen the first journey

Improve unsupported-plan resolution, cost-estimate accuracy, and engagement between visits.

Make the operating model repeatable

Configure sponsor rules and local partner networks without fragmenting the member experience.

Extend language access

Validate content and partner support together, including the language gaps reported in the pilot.

Validate a second care journey

Test the domain model against a different lifecycle before claiming a general-purpose platform.

HUMAN NEED / CONNECTED PRODUCT

Where does your
experience break apart?

I connect research, product decisions, and implementation around the work people need to complete.