When I launched Disorganized (it’s a note-taking app) d1 retention was at a pitiful 6%. During September it has gone above 25% and here I will outline what I’ve done to accomplish this.

Anonymous auth

Users hate registering, especially before they have even had a chance to try the app. Firebase, and presumably its competitors, has strong support for anonymous authentication. USE IT.

Do not cripple the anonymous user experience, and do not nag users to register with their email even if it seems like a good idea. Get out of the way of your users.

Onboarding

Onboarding is the first thing the user experiences when they open the app for the first time.

I must have rewritten it five or six times by now. From popups explaining features, to a guided tour with educational popups and texts, to what is there today: just two buttons at the bottom of the screen that the user can press whenever they like. These buttons can also be dismissed.

In addition to being the best performing onboarding variant I have tried, it is also the least invasive.

By the time a user has installed the app they are already interested in exploring it. Letting them do that on their own terms seems to be the way to go.

Best onboarding yet

The “example notes” is a popup with 4 preconfigured notes that show the different features of the app, and the video is just a 1 minute video of me explaining how the app works.
**Update:**
The onboarding has developed since this screenshot.
New buttons, new design. But one thing remains: There is nothing to block the user from testing the app on their own terms.

A/B testing

There is an interesting discussion to be had about how A/B testing complements user feedback and your own intuition when designing the app. However, for onboarding I’ve learned that A/B testing has to be a significant part of evaluating changes. At this point I do not change the onboarding at all without an associated A/B test, because my intuition has consistently turned out wrong.

Your intuition can come a long way when it comes to more advanced features, but you are so far away from “a user who has never opened the app before” that relating to them and how they think is almost impossible. So for onboarding, it’s all about user feedback and A/B testing.

Onboarding and advanced features

When I started I thought there was a standardized and calm flow to how first time users moved through the app, first discovering the basic features and then only much later looking at the more advanced ones.

I am learning that is not the case at all. People are jumping past basic features and within five minutes of using the app they are already giving feedback on features I thought they would not touch for weeks.

This is not really actionable, just something I found surprising. Users are consistently more advanced than I expect them to be.

Talk to users

You knew this one was coming…

The best way I’ve found is going to reddit and handing out lifetime premium in exchange for feedback.

It is important to require that the user initiates contact with you to get the premium, so that they already have an open communication channel when they encounter issues or have feedback.

I’ve had over 800 private conversations this way by now. Many are just one or two messages (which can still be useful), but some are substantial and give loads of feedback.

Actually do what they say

It is easy to dismiss what users say as “It is just one user requesting this, it is not important,” but I keep finding out that this is usually not true.

One user wanted the ability to draw inside the app. I was skeptical because I knew that any draw feature in the app would have to be very basic, so I didn’t implement it.

A month or two later another user requested it, at which point I decided to implement it. Now I frequently hear users claim that it is their favorite feature.

Similar things keep happening: one user requests something that I initially believe is very niche, and then eventually it turns out that it is not the case at all.

Another advantage to going above and beyond at facilitating user requests is that they will be happy to give you a great review, which is invaluable for a tiny app.

The “not my target user” myth

Similar to my last point, I hear people disregard feedback because they decided that the user in question was not their target user and therefore their feedback was irrelevant.

First of all, if you just spent a few days and some effort, that user and similar users could become your target user.

Second, user segments are not as neatly defined as you might think. Just because you think that your target group is only males between 25 and 45 does not mean that this is actually the case.

Third, their feedback can still be valuable. My mother is absolutely not in my target group, yet she has provided great feedback that has made the app better.

Developer laziness

The headlines above might sound obvious, but the main problem I am trying to get at here is that developers disguise laziness and arrogance under explanations like “not my target user,” and it kills their app.

You have to be ready to put in days of work just to address feedback from one user, because that is all you have to go on. You have to be ready to accept that your app sucks even when you think it does not, but you can always make it better.

I spent three to four full working days implementing feedback from just one user. They were so happy that they installed the app on their entire family’s devices just so that they could leave multiple five star reviews. And they were clever enough to spread out the reviews across weeks so that they would not get caught in spam filters.

Summary

A/B test everything related to onboarding
Get out of the way of the user, don’t force them to register or sit through an onboarding.
Talk to loads of users
- Don’t dismiss their feedback

Best of luck!

From 6% to 25% d1 retention