5 Keys to Android and iPhone App Development That Often Get Ignored
by Seni Sangrujee on July 08, 2011I've been chatting with a lot of folks recently, and I've noticed an interesting trend. In Silicon Valley, it's no longer the case where Everyone and Their Brother has an idea for an iPhone/Android app, it now seems like Everyone and Their Brother now has an app in the AppStore and Android Market already.
Experiences seem to be mixed. Some have had hits, but more often than not, people aren't getting the downloads that they were anticipating and languish in the "I built it and no one came" state.
It's definitely a different environment now than when both the AppStore and Android Market first opened, and downloads are tougher to come by these days. In the early days, it seemed like you could publish anything and get a nice number of downloads from an app-starved userbase, but both stores are so crowded these days that I've significantly adjusted and refined my approach from back then.
Here are 5 things that I spend a lot of time on that I've seen many indie app developers neglect:
1. DiscoverabilityThis is the most important thing I think about when working on a new app. If no one downloads my app, there's no point in writing it, so I want to do everything I can to get my app in front of my target audience. This was a tough hurdle for me at first having to remove my Engineer hat and putting on my Entrepreneur hat and focus so much on this when the comfortable thing would be to go back to coding a feature that I think is cool but that no one may end up using.
If you look at most of the apps out there, there's only a handful that are truly innovative, most just aren't that interesting from a technical perspective. And I've seen some apps with very impressive technology that just sit there and get ignored. It's fun to write a technically innovative app just for sake of innovation every so often, but it doesn't always pay the bills.
The funny thing about App Discoverability is how much it changes over time and what a moving target it is. I spend a lot of time studying successful and unsuccessful apps to see how people find them, but I'm reluctant to post my findings here since in a few months things will be completely different. I use my less popular apps as trial balloons to experiment with different techniques to gauge what's currently working or not.
App Discoverability is the thing that keeps me up at night these days. When I was first starting out I was deathly worried about that critical bug that crashes and loses someone's data or worried about scaling issues if an app is a hit and take down my servers. But these days I'm pretty confident in my abilities to not lose someone's data, and I look at scaling problems as a good problem to have and means I'm on the right track with a concept. So my biggest worry now is wasting time on something that no one uses.
2. First Time ExperienceIf I've done a good job with Discoverability, my second area to focus on is the First Time Experience. Now that I've gotten a user to find the app and (hopefully) download it, I want to make the First Time use case is absurdly smooth. I see a lot of people spend all their time on the everyday/repeat use case and completely ignore the first-time user, and the newbie user never gets converted into a repeat user.
One aspect of this is an Intro screen upon initial launch or possibly a Tutorial or Help screens, but that's not everything. The Power Users that use my apps every day want everything easily accessible, but the Newbie user would get overwhelmed by all the options and have a bad First Time Experience. It's a tricky balance, and while I'm developing in app I often fall into the trap of optimizing for the experience as an expert user since I'm so familiar with the app myself and initial the person that's just trying to figure out what the app does.
The goal I'm trying to achieve here is simply to keep the user from uninstalling the app and to get them to launch it a second time.
3. ViralityI get a lot of emails from happy users telling me that they tell all their friends about an app, which I love to see, but it also means I could have done a better job of getting them to get their friends to join by including viral elements within the app.
Here I'm talking about things like Facebook integration, sharing things via email or text messaging. If I'm trying to decide between two features to implement and one feature enhances the solo experience while the other helps make the app more social or viral, I try to tackle the viral feature first and the solo feature can wait for a future release.
If the app doesn't include an easy way for people to get others interested then maybe I need to completely redo my approach or scrap the idea entirely.
4. Return ExperienceThe questions I'm trying to answer here is: "Why should I come back to this app again?" and "Would I still use this app after 6 months?"
Even though I tend to advocate "throwaway app development", that is to code something quickly, release it out there, then refactor and clean things up only if/when the app is successful, I'm not a fan of "throwaway apps", apps that you install for a few uses and then uninstall.
I prefer to work on apps that provide lots of repeat value for the user. After hopefully cracking the good First Time Experience problem in a particular app, I like to look at the app experience from the perspective of a daily user after having used the app for 6 months.
Actually, looking at my Analytics, I only have one app that has true daily users, which is my Prayer App where people really use it every day. Some of my popular apps like my Wine App or Movie App are more "weekend apps" where the app usage spikes hard on the weekends. Some of my apps in the pipeline fall under what I call "weekday apps" targeting Commuters or IT departments of medium-sized companies.
5. Launch PlanThe final thing that I often see ignored is getting everything ready for Launch. I've fallen into this trap myself. For my first app, I was coding up the last minute and then slapped things in the AppStore quickly together at 3am to get it submitted and I made a lot of mistakes.
Now what I do is start on the App draft (for either the AppStore and Android Market) as soon as I start development. What I'm trying to do is maximize the amount of time I spend thinking about things like what to name the app, picking the right keywords, making the screenshots. I iterate A LOT on an app description (especially the first paragraph, which is usually all that gets shown initially), so I want to spend as much time as possible getting that right. I hate losing people who make it past the Discovery stage, but never reach the Download step.
There's a bunch of things to prep for an app launch that often get overlooked and it's easy to forget when things are getting close to release. I'm talking about things like "what day of the week to launch", or should the paid/free versions have a staggered launch or maybe just go with In-App Purchase off the bat. Web SEO also should have started well in advance of launch and the AppStore SEO strategy should be ready from the beginning, not added later.
Another example, is for some of my apps, I'll have spent the previous few months participating on forums where my target customer hangs out getting to understand their pain points and effectively building the app together through our discussions. In that case, I make sure to comp the folks that helped me out with App Store promo codes or just Paypal (since Android doesn't have a promo code/gift option) when the app launches to get the app in their hands ASAP. They'll either become evangelists or give me honest feedback and tell me I dropped the ball.
Damn, this post wasn't mean to be this long, but I always end up rambling when I talk about apps. I wanted to get this thought out of my head while I had a chance. Hopefully I brought up some interesting ideas to think about when you work on your next app.