CURRENT

The client brought an AI-generated dashboard and an MVP document. They pointed in different directions: the dashboard used streaks, progress, scores and strengths ratings; the MVP said the product should not be gamified.

I used the MVP as the stronger constraint. Those elements did not make it into the product. Missing a few days should not feel like failure.

The early font also felt wrong, so I pushed back and moved the interface to Satoshi for a calmer, more readable starting point.

streakprogressscore

fig. 01 — Client reference. Useful as a reference, not a product direction.

• Not in the MVP
• Missed days should not feel like failure
• Support, not performance

too much like an experiment

more space, calmer type, clearer return point

CURRENT had four roles: patient, caregiver, coach and clinician.

These were working assumptions based on the MVP, seeded data and review notes, not research findings.

Personas and information architecture helped define what each role needed to do, what they could see and where the system needed to hand off.

This was not one app with permissions added later. The roles shaped the structure from the beginning.

Onboarding took the longest because the team was still deciding what to ask first: account details, personalisation or how someone was feeling.

I explored a split layout and a chat direction before settling on a mixed flow: quick selections when possible, open responses when context mattered.

Journey maps helped identify the moments where the product needed to be careful: the first weeks, a bad night, scan week, someone going quiet or a serious flag.

split layout

visual mood without turning the question into decoration

chat directionexplored in Figma

more conversational, but question order mattered more

mixed flow

select when quick; write when context matters

I mapped the patient, coach and clinician flows, including their exits.

A check-in could continue in the product, move to the care team or route to crisis support.

Behind the interface, the belief system updates after each interaction and uses clinician-created content to shape later responses.

I designed the visible check-in, recommendation and handoff states. The belief engine, classifiers and clinical operations were outside my scope.

01Check-in

02beliefs needing support

03clinician library

04next recommendation

21 resilience beliefs in the prototype. This is product logic, not patient data.

• ordinary check-insupport in the product
• clinical concerncare team
• crisis signalcrisis resources and 24/7 line

Journal pages and check-in words stay private.

Caregivers, coaches and clinicians receive different levels of information based on role and permission.

The patient decides what can be shared before someone is invited.

This became a minimum-disclosure approach: show each person what they need without turning private experience into a shared dashboard.

Patientcontrols access

Caregiverown support flow, approved information only

Coachsupports several people, with clear limits

Clinicianwhat needs clinical attention, with context

journal pages stay private

I moved into Claude Code because of the deadline, but the layouts became repetitive while the flow was still changing.

I returned to Figma to settle the decisions, then rebuilt the direction in React.

The prototype was shared through GitHub with the full-stack developers, AI engineer, CTO and product manager.

It brings together seven connected support flows, 21 resilience beliefs and three safety and escalation tiers.

The product is in beta. There are no health-outcome or clinical-impact results to claim yet.

01Figma flows

02React prototype

03GitHub project

04frontend and backend integration