One of the key success factors in a mobile application is, absolutely, the user experience. The app market is a highly competitive environment, which has also the particularity of being prone to the change: removing and installing another app is as easy as touching twice in the screen of the device. If your product is not easy to use, intuitive and attractive, failure is guaranteed.
After analyzing how some of my colleagues use Do Not Eat That! I’ve realized that upon having to use an app for the very first time, user behaves like a child with a new toy: instead of following the rules defined by its natural design, he will choose the most awkward and unexpected way of using it.
The direct experience with my potential users has wide open my eyes. Among all the user interactions, there’s one specially relevant (and critical): the first one. This is what the experts (in terms and acronyms) call FTUE, First Time User Experience.
Diving on this topic I’ve come across reports revealing that amongst 80 to 90% of the installed apps are immediately deleted after the first use (now I understand what marketing guys refer to when talking about retention). Sadly, when dealing with user experience, you are not aware of errors until your users show you that your design does not work. That’s what has happened with my app: my FTUE strategy is wrong and I am loosing users even before they can see what the app can do for them.
My mistake is closely tied to a business model. Do Not Eat That! belongs to the growing group of free apps that offer purchases inside the application (the well-known in-app purchases, strongly used in the game segment). According to this model (also known as freemium) app developers try to minimize the impact of a dangerous idea installed inside the minds of the users: apps have to be free and for every need there is always someone offering a zero cost alternative.
In order for a freemium app to deliver any kind of income, it is a requirement to carefully choose the time when you ask for buying (new game levels, extra lives or the X functionality that is not available in the free version). Ideally, the request should naturally flow (as part of the user experience), and must be tied to a moment of top excitement or high delightment of the user, that pushes him into the acceptance of the offering.
The error is triggering the event that requests the user to buy in the FTUE, that is to say, when the user is experiencing his initial contact with the application. Obviously, starting a relationship asking for money is not a very good idea: the user will go away.
The use case that leads to this issue in Do Not Eat That! is the configuration of the first challenge (the weight loss target), which is requested to the user as soon as he runs the app for the very first time. The design of the FTUE includes some dialog boxes to drive the user to the view where he can input this configuration data. I was expecting my test users to chose the edit challenge option, to change the example challenge. Instead, the tapped the plus sign icon that leads to the creation of a new challenge. This opens an alert box informing about the need to purchase the Pro version in order to be able to create new challenges. Not too pretty.
I’ve learnt two conclusions after suffering this mistake: first of all, every app must run a round of beta-testing before going to commercial launch. On the other hand, it’s absolutely mandatory to do an intense analysis of the FTUE. Failing to do so, the first experience of the users with your app might also be the last one.