Clara Moves

A behaviour-change system for a conversational companion that improvises, designed to sit outside medical-device regulation.

problem

Clara is a conversational coach for older women who have lived with osteoarthritis for years and now avoid movement, afraid it will hurt. She improvises. No flow to spec, no branch diagram. I designed the behaviour-change system behind her, solo: no clinical writer, no regulatory consultant, no conversation-design team. What I built was the machinery underneath: a behaviour-change technique library, barriers and motivations mapped per persona, clinical cautions, and a rule keeping clinical and regulatory language separate. The programme targets confidence. Clinician insight and published literature agree: for this cohort, low confidence compounds the pain, and it is the barrier a programme can actually shift.

solution

Instead of screens, I designed rules. Clara suggests, never prescribes, and she never narrows someone's options because of their pain state. Every scene is defined by what she must never do, with pass/fail conditions an engineer can test. The hardest case: some days a user opens the app in distress, and a coach built to suggest activity will suggest one. So the system hard-stops: a fixed, human-written response, support resources, no movement content. The residual risk sits in detection, so it over-triggers by design. It fails safe.

Proving it works without becoming a medical device

The funder needs evidence of engagement and efficacy. The standard route would be a validated confidence scale, scored fortnightly, with a pre/post comparison of sedentary time. But Clara is designed to sit outside the medical device definition, under the TGA's exclusion for behaviour-change and coaching software, and scoring a health construct with one starts to look like clinical assessment.

Passive analytics show what each user actually does inside the programme, in aggregate: engagement, a fair proxy for participation. Directional self-report carries the felt side: confidence improved, flat, regressed or not sure. No scores. Together they give the funder defensible reporting without a clinical instrument. The daily check-in asks "How did today feel overall?" rather than "Did you build your confidence today?", because asking directly invites her to perform improvement for the app.

One designer, an AI harness, and a mid-build pivot

All of that design lived in one set of source files: the technique library, the barriers and motivations maps, the medical-device exclusion path, and the design decisions. I built an AI harness over those files, so every document came from the same source, not from scratch. When a stakeholder needed a different kind of artefact, I iterated on the format until it worked, then locked it into the harness.

It paid off when the funder's revised framework landed mid-build. The programme had to lean away from suggesting and tracking activity, toward reframing attitudes and barriers. Because every artefact came from the same files, that shift cascaded through nine documents instead of a rebuild.

My first documents to the engineer explained the programme the way I would pitch it to stakeholders, sketching its shape so we could co-design the detail. His verdict: waffly, reads like AI wrote it. He was right. He wanted explicit direction. Rebuilt as constraints and testable conditions, the documents also exposed where clinical and regulatory language had blurred.