Half of digital health programs built to change behavior have no behavioral theory behind them.
That's not an outside critique from skeptics. That's what the researchers found when they looked at their own field. An overview published in the Journal of Medical Internet Research in January 2026 analyzed 23 systematic reviews, covering 514 individual studies and 129,481 participants across digital interventions for sexual health, HIV prevention, and STI testing. The finding that ~50% of those reviews lacked an explicit theoretical framework isn't a footnote. It's the through-line.
The paper is technically about sexual health apps. But I'd argue the lesson here belongs to anyone building a digital behavior change tool of any kind, and I think anyone who reads the actual finding will agree.
What "theory-grounded" means in practice
This is where I want to slow down, because "use theory" is the kind of advice that sounds meaningful and gets nodded at in meetings and then does basically nothing.
The studies in this overview that had explicit theoretical grounding consistently outperformed the ones that didn't. That's the headline. But the gap between "has a theory" and "doesn't have a theory" is not the same as the gap between "cited COM-B in the product brief" and "wrote the brief with no references." It's more specific than that.
Theory-grounded interventions in this literature actually mapped their behavioral change techniques (BCTs) to a specific psychological mechanism. Goal-setting as a BCT activates a particular process: it creates a discrepancy between current state and desired state, which generates motivation to close that gap. That's the mechanism. When you know the mechanism, you can design the feature to activate it, measure whether it's working, and iterate when it's not.
When you skip that step, you're doing something more like feature cargo-culting. You add goal-setting because another app has goal-setting. It doesn't work as well. You don't know why because you didn't have a hypothesis about why it should work in the first place.
The BCTs that actually showed up
The most frequently used techniques in this literature were goal-setting, feedback on behavior, and reminders via SMS or mobile notification. These three show up across the 23 reviews consistently enough that you could call them the default toolkit.
They work. Testing uptake improved. Risk awareness improved. The tools did what they were supposed to do in the short term. But the evidence for sustained behavior change, the kind that holds up six months or a year later, was mixed. The authors are honest about this. The short-term outcomes are real. The durability question is still open.
And I'd argue the theoretical gap is part of why. If you don't know which mechanism a BCT is activating, you can't design for maintenance, only for acquisition. Getting someone to book an STI test once is not the same as getting them to think about sexual health as an ongoing practice. Those require different mechanisms, and you can't select for the right one if you're not thinking mechanistically.
Why half the field skipped the theory
I want to be honest about why this happens, because "researchers and designers didn't think about theory" isn't the actual explanation.
Building a digital health intervention is hard. The evidence base for which BCTs map to which outcomes in which populations is genuinely complicated. There are taxonomies, BCT Taxonomy v1 lists 93 techniques, and figuring out which ones are relevant to your specific context requires expertise that doesn't live in every product team. If you're a small team with a launch deadline, and you can either spend three weeks doing a proper behavioral analysis or ship with a goal-setting feature and some push notifications because those worked for a competitor, the second option is going to happen a lot.
This is a structural problem, not a motivation problem. Product teams aren't incurious. They're under-resourced for the kind of upfront analysis that theory-grounded design actually requires.
The overview doesn't address this directly. But I think it points to it indirectly. The interventions that worked best weren't the ones with the biggest budgets or the most features. They were the ones that had clarity about what they were trying to change and why a particular approach would change it.
What the 50% stat actually means for product teams building this stuff
If your product aims to change a behavior, you need a clear answer to: what psychological process does each major feature activate?
Not "this feature motivates users" (that's output language, not mechanism language). More like: "this feature creates a concrete, measurable target that the user can track their progress against, which activates the goal-discrepancy process and generates approach motivation." That's a hypothesis. You can test it. You can see whether the users who engage with that feature actually close the gap on the behavior.
If you can't say something like that for your main behavior change features, you're probably in the 50%.
The good news is that frameworks exist for this work. COM-B (Capability, Opportunity, Motivation and Behavior) is the one I see most often in digital health and it's genuinely useful for diagnosing which category of barrier you're actually addressing. The Behaviour Change Wheel that builds on it gives you a structured path from problem diagnosis to intervention selection. These aren't proprietary or expensive. They're in the literature, available to any team that wants to use them.
The barrier is almost never access to the theory. It's time and clarity about when in the product development cycle to do this kind of analysis.
When to do the analysis
The overview's findings push toward an answer on that timing question. Theory-grounded interventions did better. That means the theoretical grounding happened before the BCT selection, which happened before the feature design. You can't retrofit a behavioral model onto a product that's already built and shipped. You can add it to the retrospective and hope it informs the next version.
But doing it upfront, mapping the target behavior to a mechanism, selecting BCTs that activate that mechanism, and designing features that implement those BCTs, is what the evidence actually supports. It's also the kind of work that tends to get cut in favor of design and engineering cycles when timelines get tight.
I've seen this trade-off made in real product work. It's understandable. And this overview is a pretty clear record of what that trade-off costs in outcomes.
Jameson Daines is a senior product designer specializing in virtual healthcare. BehaviorUX is his knowledge base on behavioral science applied to digital health product design. If I'm misreading anything in the research, please let me know.