← Back to Insights

INTRO

Welcome to Insights

Jameson Daines · April 14, 2026

A few years ago I sat in a meeting where a product manager, a clinical lead, and two designers spent forty minutes arguing about a notification. The question was whether patients on a diabetes app should get a reminder at 8am or let them set their own time. The clinical lead quoted a paper she'd read once. The PM quoted a Mixpanel chart. The designers quoted a competitor. Nobody quoted a behavior model, because nobody in the room had one.

We shipped the 8am reminder. Retention didn't move. The paper the clinical lead remembered was about medication adherence in adults over 65, which was not our population, and the chart the PM had pulled was filtered on a segment that didn't exist six weeks later.

That meeting is basically why this blog exists. Not because anyone in the room was wrong, exactly. Because we had no shared language for talking about the behavior we were trying to change. Arguments without a model are just preferences wearing lab coats.

The gap nobody is filling

There's an odd split in health-tech right now. On one side you have behavior scientists writing careful papers about intervention fidelity, COM-B mappings, BCT taxonomies, the whole Michie framework. Most of them have never shipped a feature or sat through a sprint review. On the other side you have product designers running usability tests and A/B experiments, most of whom haven't read a single COM-B paper. The people in the middle, who can do both, are rare enough that they become weirdly expensive consultants. I know because I've been hired to be one.

I don't think it needs to be that way. The frameworks are not hard. COM-B takes about twenty minutes to learn. BCT v1 has 93 entries, which sounds intimidating until you realize you'll use about twelve of them in any given product. The hard part is translating the language of a research paper into something a product team can actually use on a Tuesday afternoon. That translation layer is what I want to write about.

Who I am, briefly

I'm a Senior Product Designer at Wheel Health. Before that I ran pharma UX projects at AstraZeneca and worked on the Galaxy Watch at Samsung. I have an MSc in Behaviour Change from UCL, another MSc in Entrepreneurship, and a BSc in Psychology. I built BehaviorUX because every health-tech team I've worked with has wanted structured behavior thinking, and nobody had a free tool that made it easy.

BehaviorUX is not a consultancy. It's a knowledge base plus a canvas tool you download and run locally. There's no login wall, no sales funnel, no hand-raise form that drops you into a CRM. The canvas is at behaviorux.com/download if you want to run one of the frameworks I'll be writing about.

What you'll find here

Four kinds of posts, roughly.

First, framework walkthroughs. How COM-B actually works when you're designing a diabetes app. Where the Fogg model gets the motivation side right and where it collapses too much detail. How to map a BCT onto a specific notification without hand-waving.

Second, research reactions with a product lens. Somebody publishes a paper on mental health app dropout. I read it, pull out the findings that would actually change how you'd build a product, and skip the rest. You don't have time to read the methodology section of a 40-page RCT. I do. The Linardon & Fuller-Tyszkiewicz 2020 meta-analysis of 21 mental health app trials, for example, has buried in it a detail about attention-control arms that changes how you should interpret every "our app works" press release from the last five years. I'll cover it.

Third, canvas walkthroughs. Worked examples with the BehaviorUX tool. I'll take a real product category (sleep apps, medication reminders, therapy marketplaces) and run the full canvas on it, showing my reasoning at each step. Screenshots included.

Fourth, opinions. Honest takes on what the industry is getting wrong. Some of them will be unpopular. I think the entire "habit stacking" genre of health apps is built on a misreading of the research, and I'll say so in a post at some point.

What you won't find here

No generic UX tips. There are a thousand blogs already writing about button placement and empty states. I won't compete with them.

No AI vocabulary. I won't use "leverage" as a verb. I won't tell you to "unlock your potential." You will never read the phrase "cutting-edge platform" on this site, because I'd rather close the tab on my own article.

No consulting pitch. BehaviorUX isn't for sale. If you email me asking for a retainer I'll politely redirect you to the free canvas and whatever posts are relevant.

And no rule-of-three listicle endings. If I have three things to say I might say four, or two. Rhythm should match the thought, not a rhetorical template.

Cadence

Two posts a week, more or less. Tuesdays and Fridays. Some will be 800 words, some will be 2,000. I'll err on the side of shorter when I can.

If you're a product designer, PM, or behavior scientist working on anything that touches health outcomes, this should save you some time. That's the goal. It isn't a community or a movement. Just posts I wish I'd been able to read five years ago when I was the person in that meeting wishing somebody had brought a model.

What's next

The next post goes up Friday. Topic: why 96% of mental health app users drop off by day 30, and which design moves I've actually seen move the day-30 retention needle by double digits. I'll lean on the three Headspace RCTs specifically, because Headspace has the only half-decent public evidence base in the category. There's a paper from 2019 in JMIR Mental Health that almost nobody in product design has read, and it changes how I think about onboarding for any app that depends on daily engagement.

See you Friday.

More writing

Two articles a week, all on how behavioral science earns its keep in product design.