Competing against default behaviors

Using your app is voluntary and effortful

People can always choose to use your product, an alternative, or nothing at all

In fact, not using your product is their default state of being, and you’re trying to get them to do something different and effortful in using your product. This is part of why I don’t like the HOOK model from Nir Eyal - people need to make a decision to use your app, whereas Non-Usage is rarely a conscious decision. We’re not trying to create habits - instead, we’re trying to break prior habits.

For example, if you are building an app like Notion, Tana, or Obsidian, you’re asking for more user involvement than Apple Notes. How do you outcompete default behaviors?

A user starts with Apple Notes, tries hard to make a more advanced system work with more moving parts, and then eventually defaults back to their low-effort system in Apple Notes.

Adoption requires a baseline of user involvement in order to overcome prior habits. Users must engage in certain behaviors that are different from what they were doing before in order to gain value. So how do you motivate the change?

It’s easier to facilitate people doing something they want to do than it is to convince them to do something they don’t want to do. It’s easier to enhance their desire for something they already wanted than to instill a new desire. It's easier to meet people where they are than it is to ask them to do something that is too challenging. This is why it's crucial to design for Goal Resonance and Difficulty Matching. Prove to the user that, with your product, they are capable of accomplishing their goals better than ever before. The most successful app adoptions come from projects because those gives users the motivation to learn functionalities in the context of when they are useful and persist through failures.

Failure is inevitable. Users must engage in certain behaviors in order to gain value, those behaviors are effortful, and users won’t always do the right thing. When users fail to get the outcome they want for their involvement, app designers need a plan to get users to try again and learn rather than get discouraged and switch to their default behaviors. A core principle of Continuous Onboarding is to intentionally design for failure states. In my work with GuidedTrack, a low-code Typeform/Qualtrics alternative, I was essentially designing an IDE that helped new programmers through common failure states.

When somebody is learning to program, they’ll inevitably face failure. How might we help them get back up?

This all points towards the necessity of using Behavioral Product Strategy. It’s not enough for products to be usable; finding the person’s positive motivation to use an app is crucial. We must increase the user’s self-efficacy, because generally people are more likely to choose to do something they believe they are capable of doing well. We must strive to communicate through feedback loops and learnable design, because reading or watching explainers is effortful behavior only indirectly linked to goal achievement.