28 Oct Forget About Features, Design Behaviors
Patient engagement has been called the blockbuster drug of the century. In the booming frontier that is digital health everyone is trying to activate and sustain end users. Despite digital health funding and healthcare consumerism advancing at a faster-than-ever pace, abandoment statistics reveal that approximately 50% of people who start using a digital health device stop using it within six months. Certainly more efficacy data is needed, but why, with such a proliferation of digital health solutions, are engagement trends so poor?
Because partnerships between technology developers, behavioral scientists and designers for better healthcare is new. And very much needed.
Learning From Failure
In 2005, while doing my doctoral work at Columbia University’s Department of Health & Behavior Studies, I embarked on a year-long project to develop an online exercise motivation program. I was positioned full-time at Go Ask Alice!, Columbia’s Health Education Program, and it was my job to leverage technology for the increase of physical activity among university faculty and staff.
Taking everything I knew about health behavior change theory, I partnered with technology leaders and engineers to build a personalized dashboard that enabled users to log their exercise time. We called it “The 100 m.i.l.e. Club” (Minutes I Logged Exercising). Users could plan, track and see their exercise progress. The idea was simple: any user that performed and logged 100 minutes of physical activity per week would be entered into a lottery to win a small prize like a t-shirt or water bottle.
It was a big failure. Or rather, a typical digital health failure. We saw a surge of sign-ups within the first month. Then, new users dwindled….fast. Most users remained active on their dashboards for 2-3 weeks, then fell off.
I was stumped. We did everything “right.” We spent significant time and money, and worked hard to ensure behavior change theories were at the core of our development decisions, yet still, attrition rates were 60+%.
Designing For Behaviors
After experiencing and observing many tech-enabled health behavior change failures and successes over these last 10 years, I realized one of the biggest reasons “The 100 m.i.l.e. Club” (100MC) failed was because we developed for an outcome.
Our goal was to “enable people to exercise more.” That’s a great goal. But we did not do any strategy to specify exactly how that would happen.
We should have designed for behaviors:
- Know your humans. Understand the people you are designing for before you build anything. User research sheds light on how, when, and why people behave. We did zero user research during the 100MC project, and as it turned out, our users were not incentized by a free water bottle. They wanted to meet other people at the university to exercise with, and nothing about our platform connected them to each other. Find out what your users want and prioritize behaviors accordingly. Empathize with their feelings and motivations. Write a Point of View (POV) statement to clarify their needs. Had we known our users for the 100MC, a POV statement might have been Columbia University staff members need to connect with other staff members because they want people to exercise with during their workday.
- Define target behaviors. The very definition of ‘engage’ is ‘to participate.’ Meaning, to do something. What do you want your users to do? The answer must be concise and small, like “eat one apple every Monday.” If your goal is to help people lose weight, for instance, then list all the really small, specific behaviors that might impact that goal. I learned how to define a behavior from Dr. BJ Fogg. Currently, one of my favorite tools to use is the Fogg Behavior Grid. It guides you to type a behavior according to familiarity, frequency, intensity, and duration. An example for the 100MC might have been to log exercise minutes on the dashboard immediately after lunch every Tuesday for the first month.
- Trigger users to act. A trigger is anything that tells your user to “do it now.” An external trigger is something – an alarm, e-mail, item, a person – that your user physically interacts with. An internal trigger – a feeling, thought, memory – is inside your user’s head. External trigger design is easier, so experiment with ways to trigger your users regularly to avoid the novelty effect. We triggered 100MC users with e-mails and paper fliers, none of which worked after a few weeks. Figuring out how a behavior can be triggered is critical for user engagement. I primarily source the Hook Model and the Fogg Behavior Model for guidance on trigger design, and always ask my design peers to create the visual (or other sensory) experience.
- Enable behavioral practice. If you want your users to act more than once, then you must find ways to reinforce and reward for repetition. Feedback loops offer one form of reinforcement. Another is to place the behavior in a new and meaningful context. The simpler you make the behavior, the more likely someone will engage. Practice is important because it builds self-efficacy, trust, and opens the door to habit formation. The 100MC didn’t offer users any reason to practice, and the log in process was laborious.
- Experiment! All of this happens with ongoing user research and testing. Experiments are needed to know what works and what doesn’t, so validate your decisions by testing with your users. We launched the 100MC and never attempted a single iteration. Behavior change is dynamic, so digital health solutions must be too.
During development of the 100MC, we kept wondering “can we build it?” The right question would have been “what will happen if we build it?” Forget about features, design behaviors. Tying strategic behavior design to engagement outcomes will lead to more pratical and digitally relevant solutions. Companies outside of healthcare, like Opower and HelloWallet, are doing this very well. Digital health companies doing behavior design are starting to publish efficacy outcomes (like Mango Health, Omada Health, Spire, and Healthvana), Even the NIH encourages technology development be guided by both evidence-based behavioral strategies and user-centered design principles. So gather round ye technologists, scientists, and designers.