I"ve been wondering lately what it means to create/deliver a successful mobile app. Competition in the app business today is so fierce, you have to develop/deliver no less than the possible best and most fluid app ever to stay in the game. I"ve been a SQA engineer in the mobile world for 4 years now, so for me delivering great apps is really important. Since you won"t find a recipe for success in just one article I"m going to share with you my findings and personal experiences, to help you build your best app yet.
There"s really no app out there popular on web that has not been ported to mobile. Since 2011 when the mobile platform hit critical mass is constantly growing. Just to give you an example, last year Facebook mobile daily active users exceeded desktop daily active users and since this is old news I won"t "dwell" on this subject any longer. You must be a "believer" by now.
For me, as a user, a successful app means it"s useful, delightful, easy to use and it"s highly ranked in app store. As a QA, success means delivering an app that has a delightful design, has a good performance (smooth, fast) and is bug free (as much as possible).
Creating useful and innovative mobile apps isn"t rocket science, but there"s really no way I can tell you what app you should build to be successful, earn a lot of money, get famous, etc. Both really useful apps and those created for people who just want to "pass time", can find success and hit thousands of downloads. There are lots of examples out there of people who wanted success and got it, but there are also people who develop for a hobby or beginner developers that want to prove to themselves that they can indeed build an app. An example of a very popular app is "Angry Birds", which got to be a phenomenon. Today you can find this app on all platforms (mobile or web), movies, cartoons, toys, etc.
Also very popular today (people spending hours playing) are the games to help the user "pass time", like "Candy Crush Saga", a game that some people are still obsessed with. There are stories with happy endings for the developers of games like "Threes", "Luckiest Wheel" or the popular "2048", people who never anticipated the success of their apps, but there are also stories of people who couldn"t handle the pressure. An example would be "Flappy Bird" app and if you haven"t played the original game then too bad. The developer (Dong Nguyen) removed it from App Store and Google play, stating that his life got "too complicated". He claimed to have earned 50.000$/day just from in-app ads. Intentional or not, Nguyen"s announcement of the removal of the game has turned into what could possibly be the most genius act of marketing in the history of the app market, because the number of downloads exploded after his post on Twitter. You can find a bunch of copycat apps in all platforms though, trying to achieve the success of "Flappy Bird".
If you are a developer / QA working on a mobile project, I"m assuming you already have the details of the app, your mockups, requirements and the platforms for which you need to run the app are decided, so you already have a starting point. Otherwise follow just these pretty simple principles to get started:
Facebook app went native, LinkedIn app went native. Should your app go 100% native also? Yes. I know developing a native app can seem like a daunting task, but from my experience it"s totally worth it. When the comparison is made, the perceived benefits of developing an HTML5 hybrid app are vastly outweighed by the real benefits of the native app experience. The most important factors, monetization, performance, user experience, security, are all skewed heavily in favor of native apps. So, this shift toward native apps is not a trend that one can afford to ignore. Part of what fuels this rise is what makes mobile computing a unique experience: native applications and the rich user experience associated with them.
There"s a huge amount of money at stake in their respective app stores, so both Apple and Google are no slouches in ensuring that their mobile operating systems are updated to be compatible with the latest and greatest features on the market. Here again native apps win out: they will be able to take advantage of OS updates and innovations quickly, in ways that are simply impossible for web apps.
When it comes to building native apps, building for all mobile platforms altogether is not a good idea and in fact you better build for one mobile platform first. Believe it or not, choosing the first mobile platform to build your app on has everything to do with the end user"s behavior and little to do with each platform"s ability. By now, both iOS and Android have reached their own levels of being remarkable and each appeal to their own type of users. If you can"t decide between them, then let me help you out:
iOS often wins over Android as the first option:
But, there are reasons when Android makes a better first option:
All that of course if you build your own app, but if it"s just a project you work on, well then everything"s decided for you, but still, there are some good points that you don"t want to ignore and that may help you and your customer:
QA is involved more and more in the requirements review, project estimations, BI analytics, so they really need to be up to date with what"s new out there. If you are a QA be ready to express your opinions, concerns, ideas, but also always be prepared to justify your input.
One of the hardest parts (or one that has been a real challenge for me) is "porting" the app from one platform to another. No matter how tempting it is to make the app look and feel similar on all platforms, remember that each of them has its own properties and features, so you may not be able to keep everything the way you want. Don"t try to make the apps look alike on all platforms; don"t try to mimic elements that you find in one platform to another. Not only that it is a bad user experience, but in the end you may need to make so many compromises that you"ll end up re-creating the app from scratch, because fixing an issue will take longer than re-doing everything. This means losing time, money, etc. For example the "ActionBar" in Android is not going to be successfully replaced by the "Application Bar" in Windows Phone or the "Navigation Bar" in iOS. So it"s not enough just identifying the correspondent elements from one platform to another. The whole structure needs to be redesigned when building the app for another platform.
It"s really unlikely that a user may use the app on multiple platforms, and once it"s used to the flow of the platform, he will expect the app to behave in a certain way. Be flexible and keep the app flexible, so by the time the app actually goes live, you can add whatever feature may be needed or that has been released in the meantime.
Once you started developing the app, don"t stall. Build it, test it, put it in market place, otherwise you risk that all you"ve done so far will become outdated and all the hard work you put into it, needs "adjustments" because it"s no longer compliant to the guidelines. I experienced something similar with an in-house app that got some work done whenever a developer was available. The development took more than a year, the principles, guidelines changed a lot, plus the updates to the OSs changed "the game", so the overall work was way greater than it would have been if the app has been developed and put on market as soon as possible. Platforms give updates constantly and you do have to update the app accordingly whether it is still under development or already in app market. While you try to build the next platform app, the one on the market will give you an idea of what to do next. So you can rely on your users/customers to give you feedback and find out where your app stands.
You need to make a difference between the novice users of the platform and those of your app. You need to have the end user in mind and try to cover his needs. For example the "Back" gesture is a pillar for navigation in Android and Windows Phone, so you can navigate to a previous screen, close a virtual keyboard and in WP8 get to the previous app lastly opened. So adding buttons for navigation just because it may not seem intuitive enough may not be the best idea. We need to believe the app will be used by sharp people, and even novice users of a particular platform will get the hang of your app as they get used to the platform.
This section is addressed to developers as well as QAs. A lot of the times QAs are involved in a project 100%, from specs to shipment, so knowing a few things about how to make your app more "discoverable" will help you and your client. Some of the features you may not have control over, like a platform showing results of a search in market by the reviews and recommendations, by ratings, by relation and cross-sell or by trending apps, but there are a few ways to influence those numbers and make your app more engaging, because ultimately this is a cycle (the more effort you put into it, the more rates you get).
Here are some items discussed on Google I/O 2013, but can also be applied no matter the platform. First of all the app metadata is important:
Think about targeted users, if you have any. Their reviews will help you in charts. You don"t want to be pooled down in ratings with negative reviews from people who are not even targeted, so try to exclude that category if your app is not addressed to everyone.
There are 5 things you can do to improve the process of making your app discovered:
From my point of view, as a QA engineer, a successful app means building a robust app, that performs great, is delightful to use and gets a lot of long installs, good reviews and rates. Intended of not, all those apps mentioned in the beginning of the article have something in common: they follow the Kano Model.
In the figure below you can see the bottom curve which shows capabilities that are expected by the customer, but aren"t necessarily a selling feature, meaning you may have a great idea, but you"re limiting your users with some basic functionality.
This way you won"t get noticed; providing only the necessary will get you as far as the lower right corner, leaving your users indifferent. Why should the users get your app instead of another similar one, right?
The middle curve - Performance/Linear - are capabilities that have a linear relationship to customer satisfaction. In other words, the more you provide, the happier your customers will be. Flappy Bird (the original) was so popular because it had something that the other copies out there are missing: a good performance and unflinchingly difficult levels. Not even the apps that are believed to be the ones that the developer got his inspiration from were that good (like "Piou Piou vs. Cactus").
The top curve shows capabilities that are unexpected by the customer. Their presence can improve customer satisfaction greatly (take "Angry Birds" for example), but not having them will not be a deal breaker for the customer ("2048").
Knowing which features and capabilities meet your customers basic needs, which features will excite them, and which features they are indifferent to will help "what" you decide to focus your resources on. So as long as you try to reach the upper right corner, you"ll be fine. Of course, as seen, luck has a lot to do with the success of an app, but remember that if you don"t buy a lottery ticket, you will never win the big prize; so get started today.
de Ovidiu Mățan
