Software Design: The "Come Back Later" Problem

By Spicer Matthews

come back later

Once upon a time, software was very different. You did not have app stores. You could not download free versions. You could not simply create an account and run the software from your browser. Software required commitment.

Back in the day, if you wanted software, you got in your car and drove to Staples and engaged with the sales doob about which software was perfect for you and your computer. Once you decided on the software you were given a shrink-wrapped box with a CD inside. Oh yeah, you also had to pay for it. And software was not cheap in those days, either.

Before you ever installed your new software you already had a pretty big commitment. You spent time at Staples. You spent your hard-earned money. And typically, you could not return the software once you opened it.

After all this commitment you were not going to let this software go to waste. People would block out time in their schedule to just to sit down and learn how to use the software, going over every inch of the software, learning everything there is to learn.

Software Today

Software nowadays is almost commitment free. It is cheap. It is often free to try. It is instant (no travel required). Users have very little skin in the game. They are not committed to sitting down and learning every micro detail of software. A user has to see value right away, otherwise, they’ll simply move along.

There are generally two moments to get your users engaged. The first is the very first time they use your software (the onboarding process), and then later on when when they discover new or advanced features. The onboarding process is all about giving the user enough value to stay interested. The later moments are about retaining the user.

The Come Back Later Problem

As software designers we tend to focus more on the onboarding process. We tend to assume that if we get a user engaged upfront, they will take the time to explore the application and learn all there is to learn (as people did in the olden days), so advanced features do not have to be as simple and clear. We can throw simplicity out the window in the name of being robust. This thinking leads to the “Come Back Later” problem.

People are busy. With modern software they have less of a commitment. When they see an interesting new or advanced feature, they often take a mental note to “come back later“ and play with it. Most people are not willing to on the fly take time out of their day to figure something out. The problem is they never seems to find the time to come back and explore more.

Often, it is the advance features that lead to free users converting to paying customers. The feature the customer told himself he would come back to later might just be the feature that convinces the user to upgrade. As software designers we need to build simplified interfaces that people do not have to come back later to.

Sometimes it is better to over simplify a feature. Throw out functionality. Do whatever it takes that people just get it. Make it so a user does not need to come back later, because he will not.