Suggestions for App Developers
Over the course of a couple of years developing applications for any platform (even though my experience is bound to Windows Phone), you learn a couple of tricks that might not be that obvious to someone who just starts in the highly dynamic and competitive world of stores and app marketplaces. Here are some wisdom breadcrumbs that I have learned, that might help you to get a bit ahead and make your application more successful.
I am not going as far as calling this advice, because experiences might vary and I am still learning, but some points remain abstracted out and universal.
This is as obvious as it can get, really. This topic was discussed over and over, and at the end of the day - the app with better reviews will always win over the one that might have a better core, but is reviewed less or with worse ratings. Which brings us to the next point.
Ask Users for Reviews
Initially, I was fairly hesitant to ask people to review my app. After all, if they are using it, they will eventually find time to review it, right? To some extent. After I launched one of my apps, I noticed that a large influx of reviews was coming when the app itself was featured somewhere - either an online publication or a the Windows Phone Store. Steadily, the review numbers grew to 20-30. With a new update, a couple of other reviews would pop up, but that was too slow. To get more visibility, I decided to add a prompt that would ask the users to review the app on every 5th launch. If the user says "yes", the app will navigate to the Store review page. If the user selects the "no" option, the app would continue execution but would ask again on another 5th launch.
At this point you might think - that's too invasive. If I said I don't want to review your app, I won't. But it worked. The number of reviews grew exponentially and I jumped from 100 to 200 and 400 in a couple of weeks. That first 100 was accumulated over a year - to give you a perspective over how much a simple prompt can do.
Beware the Feature-CreepYet another topic that can easily be applied to any software project outside the app universe, but it is especially critical in the context of the mobile app project you're (going to be) working on. As the product grows, you will receive feedback and people will want more capabilities added. Weight in on how much something really needs to be in your app. Is a weather indicator really necessary in your podcast player? What's more dangerous is handling features that look like those can be useful for the problem the app is solving, but not really to the extent that would warrant developing a bloated bubble. Do you really need integration with every possible cloud storage service for your document editor? Probably not. Yes, there will be users that will want Box, Dropbox, Amazon EC2, and Google Drive integration, but because you are on a Windows Phone, and all Windows Phone users have a Microsoft account, so they inherently get SkyDrive storage - that should probably be your target.
Simplify, simplify, simplifyIf your users need a tutorial on how to use your app, you're doing something wrong. While on a desktop you can assume that the user has some time to get accustomed to the product, that does not apply to mobile devices. Think from your own point of view - how much time are you willing to spend to learn the in-and-outs of an application? Probably not more than a minute. If a game or an app are too complex, its chances of being closed and rarely opened again are pretty high. To reduce that, make sure that:
- You follow the platform design guidelines, so that users don't have to adapt to your app specifically and would rather be using the ideas adopted from the OS.
- Do not use small font. Mobile screens have a limited size as they are, no need to complicate the user's life even further.
- Value your screen real estate. Each screen should carry a limited set of functionality that is related to its own context, instead of putting everything your app can do on every page.
In other words, apply the idea of KISS.
Create a Personal Connection to your UsersBelieve it or not, people appreciate when you acknowledge their feedback and comments. Engage with your users through email, Twitter (or any other social network for that reason) and you will be able to retain a loyal user base that will be willing to test your product and be more open in terms of disclosing issues and potential edge cases. Obviously, this means that you have to have well-advertised (e.g. in the About page) contact channels.
Not all feedback will be good, some emails/comments you will be receiving will be users venting on how horrible your product is and how could anyone with a pair of eyes have possibly designed that, but you will also get a ton of ideas and test cases that you wouldn't have gotten otherwise. So it's worth the effort.
No product will be perfect on launch. Doesn't mean we can't aim for that, but it's rarely the case. Respond to feedback quickly and fix/add functionality as fast as possible. Having a well-maintained product leads users to trust your commitment to them as well as to improving their experience.
The Starbucks Coffee Fallacy
This might not be the exact scientific term for it, but often times I notice developers complain that how come users are not willing to spend $0.99 on an app and yet buy a $5.00 coffee every day. Here is the core of the issue - when buying a cup of Starbucks cappuccino, you are guaranteed to get the same cappuccino in every single Starbucks establishment around the country. With an app - not so much. What you get for the given price is a gamble, especially if the app is new. The user can take the developer's word that "my app is awesome and you will love it", but what if not? An app purchase will be with you forever, and even though not costing much, the feeling of being stuck with something makes you think twice before spending anything on that object/project. Here is the place where reviews come in and push new customers to actually invest in your efforts.
That's it for now! More to come within the next year, as I work on more apps and get more experience.