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?

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.

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.

While there is a lot of wisdom to this idea, I've noticed a counterintuitive trend in apps built for power usage. When the user starts out, they have a GUI (Graphical User Interface) that helps them learn how to do things. As user skill level increases over time, they can actually disable elements of the GUI, decreasing the clutter on the screen that they no longer need as a memory aid for how to do X or Y.

Take a look at how Figma shows you all of these buttons you can click that would modify your selection. This helps the new user discover what is possible!

Eventually, Figma users will learn keyboard shortcuts. At this point, they can press a shortcut (command+period on Mac) that will disable most of the UI. Now they are just interacting directly with Figma's infinite canvas data structure. Advanced users speed up and enter a flow state with total immersion. Manipulating a file feels as intuitive as reaching to grab something. It's just like movement.

I recently saw a post on LinkedIn where someone shared a five page PDF filled with keyboard shortcuts in Excel. Can you imagine how rewarding your mastery would feel if you learned all of them, and were able to interact with just a spreadsheet? No BS clogging your screen, just rows and columns? If you’re like Jason Chan and know how the data structure works and how to move... wouldn't the toolbar at the top feel like wasted screen space?

Luckily, you can hide it! Much better.

In GuidedTrack, a new user writing a survey would use the toolbar and fill out forms that generate code for them based on their inputs. Click insert and it places the code into your program.

Through repeated exposure, users begin to remember how to write the code on their own. At this point, they only look at the toolbar occasionally. They aren't slowed down by having to click through a bunch of different screens. The user actually gets faster, as they're able to produce code as quickly as they can type. Most apps only have a GUI, and therefore, creation will be just as slow every time.

The pattern for progressive reduction seems to be as follows: the GUI provides training wheels to understand the data structure of the application, and power users eventually want to interact with the application's data structure as directly as possible, with as much information density as possible. The next question becomes: How might we provide a smooth learning curve from new user to power user?

I keep coming back to this video from Mike Caulfield, where he describes the concept of “hard to learn, easy to use” in a way that feels relevant to Continuous Onboarding, so I thought I’d share my thoughts.

Before Douglas Englebart invented the computer mouse, we had the light pen. You can think of it sort of like a stylus people would use on their computer screens. People were already familiar with how to use pens on paper, so within 5-10 seconds, people could figure out how to use it. The mouse was trickier. It had multiple buttons, and moving a cursor around on the screen by moving your hands on a table was a weird notion for the time. A mouse afforded more possibility and comfort, but it had a learning curve.

When Doug would put two people against each other on the same task, mouse users were initially slower, but "very quickly they start[ed] to outpace the person with the light pen, and they start[ed] to achieve a fluidity of speed and expertise that the person with the light pen never achieves."

We live in a world of light pens. We infantilize people with software that is built to be intuitive from the start but can't do anything serious because the developers were scared of requiring the user to learn anything new.

From the video:

"People are bragging that infants can use iPads as if this was a point of pride rather than something horrifying… This is why we live in a world where most things are easy to learn, but hard to use. By hard to use, I don't mean that we feel they are difficult, but that we never reach our capacity to meld with these systems because we've chosen this path."

The user’s journey to expertise

Don't get me wrong, upfront onboarding can be a perilous time. Without the right kind of supportive design, you lose users. Many apps are both hard to learn and use, and I would bet they have high churn. But we don't need to be afraid - we just need a better framework for understanding the user's overall learning journey. This is what I'm trying to communicate through Continuous Onboarding.

We don't need to teach the user everything at the beginning. We can spread learning out as long as users recognize that their own involvement is bringing them closer to goal accomplishment. That is what motivates them to keep at it. As designers, we need to think of user involvement as a resource we get to tactically spend, while recognizing our tools to increase user involvement through motivational techniques.

I'm a big believer in "low floor, high ceiling." It shouldn't take much effort or time to gain value out of the system. As the user's skill grows, user goals will get more sophisticated and varied. If we want to retain users, we need to cater to their six month goals just as well as their first week goals.

“North star for Roam Research is Excel. Easy enough for 750M people to use, powerful enough that you can spend your whole career working 40+hr a week in it and still find new ways to use it. Low floor, High Ceiling - to quote Gordon Brander”

- Conor White-Sullivan

“Intuitive design" should be less about designing an app with immediately obvious interactions and more about design that builds intuition through feedback loops. This distinction is especially important if you're building an innovative product, where users lack prior intuition.

I wish app developers and designers would think seriously about creating a smooth learning curve from novice to expert. What are the stages of development, and how do we facilitate the ramp up? How are users likely to fail along the way, and how might we help them recover? Continuous onboarding! I don't get why everyone expects all onboarding to be upfront. We should instead focus on the behavioral science of building expert intuition and facilitating goal accomplishment for inspiration.

The question we need to ask is: how might we make it rewarding to progress along the path to power user?

Preview

In my next newsletter, I’ll either be talking about:

• Clippy. It’s such a juicy historical Continuous Onboarding example, I have to write about it. It’s instructive in the ways that it failed, and modern LLM technology might make its better ideas possible. Many of Clippy’s fundamental design considerations are still valid.

• My experiments using Langchain and GPT to support my writing process.

• Designing for failure states. This is one of the most important parts of my strategy for retention. When your user inevitably fails, how do you decrease the likelihood that they give up, and increase the likelihood of forward progress?

I was somewhat torn when I started writing the book whether to make its subject Continuous Onboarding or Behavioral Product Strategy. Continuous Onboarding is a better concept handle for people to latch on to and speaks more clearly to a problem. However, the former is a component of the latter, and my worry was that I would need to provide so much context that I would end up talking about BPS anyway.

A solid outline, rough around the edges

And reflections on the process of ordering hypertext into longform

I’ve written an early, incomplete outline of my book. I'm still not sure where to best integrate my case studies, and I'm definitely missing a bunch of pages. I also want to add more examples from my observations (as opposed to just my own case studies). However, this feels generally right, so I’ll probably make adjustments to this outline instead of making new ones.

I feel like I'm making progress. When you see green highlighted text, it’s most likely a page you can already read on my website. In that hypertext medium, everything is so densely connected that it becomes shapeless. There are a few starting points, sure, but I can’t count on any two readers having a common experience. This is generally a strength of hypertext; ideally, the reader clicks around, following their curiosity, and quickly ends up on a useful page or fills in whatever knowledge gap they have. With a book, most people will read it beginning to end.

I wonder, if you read the pages in my early outline’s order, would the concepts make sense? Would you come to the same conclusions and theory I’ll present in the book? When you get to Chapter 10, will you have all of the prerequisite knowledge required to understand from Chapters 1-9? Linearization is hard. Especially with the case studies from my own work, as they are generally a synthesis of principles I’ll discuss throughout the book.

Giving the book a frame is incredibly motivating. Looking at this outline proves to myself that I have enough valuable knowledge to say “the world needs this book.” It’s teaching me new things about my beliefs, while making them more digestible to a wider audience.

Soon I’ll put a more concerted effort into placing words into the document. As I’ve been outlining, I’ve been occasionally updating the contents for a page that I know is gonna make it in somewhere, incrementally formalizing it to the point where it’s publishable. I still have a mountain of revisions and rewrites to make it all flow. With hypertext, I often use a link to a page to communicate its ideas concisely, so the pages on my site are short and atomic. As Andy Matuschak points out in “Evergreen Note Titles are like APIs”:

When Evergreen notes are factored and titled well, those titles become an abstraction for the note itself. The entire note’s ideas can then be referenced using that handle (see Concept handles, after Alexander). In fact, this property itself functions as a kind of litmus: as you develops ideas in notes over time and improve the “APIs,” you’ll be able to write individual notes which abstract over increasingly large subtrees.

So if I’m using a page on my site as a section in my book, I’ll need to take its linked pages and expand on them in place. I can only use concept handles as shorthand if I’ve already presented the ideas earlier, or if I plan to give them a section immediately after.

However, I’ve been surprised at how well many of the web pages hold up. To determine whether a series of ideas actually flow together, I’ll read a section of my outline and try to “present” on it. Afterwards, I’ll review what I already have written and find the main points were already there. In a sense, it feels more like I’m composing than writing a book.

Things I’ve been reading:

User Driven UI: An approach to continuous onboarding using a chatbot that progressively gives the user new tools. I’ll probably give my thoughts on this piece its own newsletter at some point. His specific solution aside, I was just thinking about “User directed experience” as a frame for my solution to the hard problem of horizontal product onboarding.

Failure margins and feedback loops: Discusses ways that video games deal with failure states, how “failure” is not necessarily a binary but could have wider margins, and how to help players learn from failure. This will be useful for writing my section on failure state recovery.

It's not just horizontal products though. Continuous Onboarding applies to most apps that aren't just "open, press a button, and close." Are you continuing to add features over time that would benefit users that are more than a month into their journey? How are users going to find those features and mentally connect them to greater goal accomplishment? Other examples include Substack, calendars, email clients, PDF readers, etc.

User goals change over time. The goals they have six days in are going to be different than the goals they have 6 months in, so it needs to be the case that user skill level increases over time in order to match their changing goals. Apps that are responsive to changing user goals over time foster continued user buy-in, so it makes sense that the app should continuously teach people how to use its app better.

Continuous Onboarding never stops. As users accomplish more of their goals, their self-efficacy goes up. They feel as though the effort they've invested was worthwhile. Through learnable design, their mental models align with how the app's, and things "just make sense." Both adoption and retention go up, allowing you to escape the Sisyphean cycle of acquisition and churn.

Continuous onboarding is explicitly designing an app to facilitate the user's growth from beginner to power user, recognizing that's not all going to happen in one day. Users feel heard and capable, so they stick around for longer.

It should be noted that some apps have a more expansive range of potential use cases than others. It may be the case that the user can learn your app in 10 minutes and then be done learning. The important thing to Continuous Onboarding is to think about Goal Resonance- how will a user discover that the app helps them accomplish a goal and execute the sets of behaviors that enable them to accomplish said goal? The user may have a lack of imagination as to what user goals they can accomplish, so how can we expand their conceptualization of the product's utility?

"Explainer content" (documentation, app tours, videos, etc.) is valuable, but isn’t scalable. Most people ignore explainer content. Learnable design, on the other hand, means that, as the user attempts to do something, the app communicates how it works through feedback loops. Make the impact of the user's actions more clear and immediate, while signaling how it brings the user closer to or further from their goals. Pay attention to the user's choices, and based on those, connect users to the functionality that matches their intention.

In many ways, this post is a rough outline for the whole book. If you click around the links, you’ll find long trails to follow. My task now is to figure out how to package it all to make sense and flow well in a linear order. As always, please comment any thoughts or questions!

When most people think of onboarding, they think of upfront onboarding, which involves holding the user’s hand for 10 minutes before letting go forever. Continuous onboarding never stops guiding the user towards behavior that will elevate their usage and help them accomplish their goals. No matter where the user is in their journey, you can count on them learning what they need to be successful. Skill improvement will be a simple byproduct of usage as users discover new features precisely when they need to. With continuous onboarding, users resonate more with your app and what differentiates you from your competition. Escape the sisyphean cycle of user acquisition and churn by successfully fostering continued buy-in that is resilient to changing user goals and skill levels.

I’m writing this book because continuous onboarding is one of my most important contributions to software/behavioral design, but my current writing is on a hypertext website and needs to be consolidated. I’m writing a book because I want software teams to have a resource they can read beginning to end and leave with actionable insights. I’ve helped over a dozen startups increase growth metrics through product design, and now it’s time for me to write a playbook that sums up what I’ve learned so far, filled with examples from apps I’ve used and worked on and video games I’ve played. 

I’m spending my time revising, expanding, and adding some extra flair to the research I’ve done already, with the goal of having a first draft available in two months. With this newsletter, I’m inviting you into my journey so you can follow and sponsor my process. In the free version of this newsletter, I’ll share weekly project updates, talk about what I wrote that week, provide relevant musings / section drafts, and detail the experience of writing. Paid sponsors will get access to Loom recordings of writing sessions, office hours, an early draft of the book, and a free copy once it’s published. I’ll even throw in special mentions in the acknowledgements.